Repository navigation
fix: stop people in timeout from opening issues - #944
nunomaduro merged 3 commits into
Conversation
…spect-timeouts # Conflicts: # KNOWLEDGE_BASE.md # resources/js/components/issue-command.tsx
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Enforce and report issue timeouts routes/web.php, resources/js/components/issue-command.tsx, tests/Feature/Controllers/UserTimeoutControllerTest.php, KNOWLEDGE_BASE.md |
The issue route adds PreventPostingInTimeout while retaining its throttle. The client shows timeout details for timeout responses and preserves existing rate-limit and generic error toasts otherwise. A feature test checks the forbidden response and timeout reason. The knowledge base lists opening issues as a restricted action. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Possibly related issues
- Users in timeout can still start orgs through the API #972: This issue identifies API org creation as another timeout bypass. Both changes address timeout coverage on posting paths.
Possibly related PRs
- dev-null-sh/dev-null.sh#653: Adds issue creation through the API and shares issue throttling with the web route, which this change protects with timeout middleware.
- dev-null-sh/dev-null.sh#501: Changes
CreateIssueanduseIssueCommand, the same issue-submission path whose timeout handling this change updates. - dev-null-sh/dev-null.sh#359: Introduces the
/bugand/featureflow throughuseIssueCommand, where this change handles timeout responses.
Suggested reviewers: nunomaduro, simonhamp
Merge Risk: 
Minimal · up to a2773
-
The timeout restriction and corresponding user-facing feedback are implemented consistently, with no merge-blocking risk identified.
Security architecture risk: 
Low · up to a2773
-
This closes an issue-posting bypass for timed-out accounts without granting additional privileges. No introduced security concern was established, but end-to-end failure and retry behavior remains partly unverified.
Retained concerns
No architecture-level concerns identified.Security review details
-
Security Blast Radius
- inferred — The affected attack path is an authenticated, timed-out account submitting issue content through the application’s existing GitHub creation capability. The PR narrows access to that capability; it does not add a new destination, credential, or privilege.
Trust Boundaries and Controls
- observed — The timeout decision and returned details derive from request authentication, not a submitted account identifier. Dialog dismissal clears presentation state only and cannot change the server-side posting restriction.
Resilience and Maintainability Implications
- inferred — A timeout refusal occurs before external creation and therefore needs no compensating deletion or success-limit rollback. Ambiguous upstream outcomes and duplicate creation on retry remain possible in the unchanged issue flow, which has no visible idempotency identity; the exact base comparison confirms this is not introduced or worsened by the timeout branch.
-
Pre-merge checks: 
5
-
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 3 files. (1 skipped: 1 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
someone in timeout can still post by opening public GitHub issues here with
/bugand/featureevery other way of posting goes through
PreventPostingInTimeoutbutissue.storeonly hadthrottle:10,1PreventPostingInTimeouttoissue.storeKNOWLEDGE_BASE.mdUserTimeoutControllerTestnext to the remotes and orgs onesSummary by CodeRabbit