Implement WorkSuggestion API and UI enhancements with Inbox features - #165
Conversation
|
Warning Review limit reached
Next review available in: 23 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThe PR adds a separate manager request path for AI tool execution. It introduces scoped approval authorization, explicit approval state propagation, suggest-only policy exceptions, new APIs, and “Allow AI tools” actions in work-suggestion interfaces. ChangesExecution request and authorization
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Manager
participant WorkSuggestionUI
participant RequestRoute
participant RequestService
participant TaskWorker
Manager->>WorkSuggestionUI: Select “Allow AI tools”
WorkSuggestionUI->>RequestRoute: POST task execution request
RequestRoute->>RequestService: Validate and authorize request
RequestService->>TaskWorker: Enqueue explicit manager request
TaskWorker-->>RequestService: Create approval-required execution
RequestService-->>WorkSuggestionUI: Return task action and status
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/web/app/api/task-approvals/route.ts (1)
154-227: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winMake approval decisions atomic with the pending state.
updateTaskActionExecutionStateperforms a normalfindByIdAndUpdatewithout anexecutionState: "approval_pending"match, so concurrent decide requests can write conflicting states and enqueue misleadingtask.execution.approvedevents. Include the pending state in the update filter, then rejectnull/409 when another request already decided.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/web/app/api/task-approvals/route.ts` around lines 154 - 227, Make the approval update in the decision handler atomic by requiring executionState "approval_pending" in the update filter used by updateTaskActionExecutionState. Handle a null update result for both reject and approve decisions by returning a 409 conflict response, and only enqueue task.execution.approved after a successful approval update.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/task-worker/index.ts`:
- Around line 884-901: Update the blocked/unsafe condition in the policy flow
around resolveSuggestOnlyPolicyOverride so bypassSuggestOnlyAfterHumanApproval
can suppress blocking only when the suggest-only mode denial is the sole
blocking reason. Keep unsafe outcomes and independent denials such as outside
allowed domains blocked, and add a regression test covering combined
suggest-only and unsafe reasons.
In `@apps/web/app/api/tasks/`[id]/request-execution/route.ts:
- Around line 67-70: Update the request body parsing in the request-execution
route around bodySchema.parse and JSON.parse so malformed JSON is caught and
returns the existing invalid-payload HTTP 400 response. Preserve schema
validation behavior for valid JSON and avoid routing SyntaxError failures to the
generic 500 handler.
In `@packages/services/task-execution-enqueue.service.ts`:
- Around line 40-41: Update the enqueue flow using explicitManagerRequest so the
resolved flag from input.explicitManagerRequest or
input.payload.explicitManagerRequest is written into the payload published to
the outbox, rather than publishing input.payload unchanged. Preserve existing
payload fields and add a test covering only input.explicitManagerRequest set to
true.
In `@packages/services/task-execution-request.service.ts`:
- Around line 76-83: Update the duplicate-handling flow around
getPendingApprovalTaskActionForTask and the request creation logic to look up
the existing action using this request’s idempotency key, including actions in
the requested state. When found, safely retry the deduplicated outbox enqueue if
needed or return the existing request state, instead of rethrowing the
duplicate-key error; preserve the current behavior for genuinely new requests.
---
Outside diff comments:
In `@apps/web/app/api/task-approvals/route.ts`:
- Around line 154-227: Make the approval update in the decision handler atomic
by requiring executionState "approval_pending" in the update filter used by
updateTaskActionExecutionState. Handle a null update result for both reject and
approve decisions by returning a 409 conflict response, and only enqueue
task.execution.approved after a successful approval update.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 3949a8b0-65c3-46cb-adf4-c97a1cdf8314
📒 Files selected for processing (27)
.changeset/v2-p2-execution-approve-separate.mdapps/task-worker/index.tsapps/task-worker/services/suggest-only-execution-gate.tsapps/task-worker/tests/suggest-only-execution-gate.test.tsapps/web/app/admin/task-approvals/page.tsxapps/web/app/api/task-approvals/route.tsapps/web/app/api/tasks/[id]/request-execution/route.tsapps/web/app/work-suggestions/[id]/page.tsxapps/web/components/chat/task-panel.tsxapps/web/components/work-suggestions/inbox-approvals.tsxapps/web/components/work-suggestions/work-inbox-triage.tsxapps/web/components/work-suggestions/work-inbox.tsxapps/web/components/work-suggestions/work-suggestion-detail.tsxapps/web/jest.config.cjsapps/web/lib/utils/api.tsapps/web/test/inbox-approvals.test.tsxapps/web/test/task-approvals.route.test.tsapps/web/test/task-request-execution.route.test.tsapps/web/test/work-inbox.test.tsxapps/web/test/work-suggestion-detail.test.tsxpackages/services/__tests__/authorization.service.test.tspackages/services/__tests__/task-execution-enqueue.service.test.tspackages/services/authorization.service.tspackages/services/package.jsonpackages/services/repositories/task.repo.tspackages/services/task-execution-enqueue.service.tspackages/services/task-execution-request.service.ts
| const existingPending = await getPendingApprovalTaskActionForTask(input.taskId); | ||
| if (existingPending) { | ||
| return { | ||
| taskAction: existingPending, | ||
| enqueued: false, | ||
| alreadyPending: true, | ||
| }; | ||
| } |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Recover retries from the requested action state.
This service creates an action with executionState: "requested", but duplicate handling searches only for approval_pending. If a second request arrives before the worker creates the approval action, Lines 138-145 return no action and rethrow the duplicate-key error.
The same state mismatch makes a request unrecoverable after a transient outbox enqueue failure. Find the existing action by this request's idempotency key, then safely repeat the deduplicated enqueue or return the existing request state.
Also applies to: 104-147
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/services/task-execution-request.service.ts` around lines 76 - 83,
Update the duplicate-handling flow around getPendingApprovalTaskActionForTask
and the request creation logic to look up the existing action using this
request’s idempotency key, including actions in the requested state. When found,
safely retry the deduplicated outbox enqueue if needed or return the existing
request state, instead of rethrowing the duplicate-key error; preserve the
current behavior for genuinely new requests.
4420304 to
3b4f3a4
Compare
6bdcc4b to
98f7823
Compare
98f7823 to
02bc181
Compare
02bc181 to
9918a05
Compare
9918a05 to
d093fff
Compare
- Introduced explicit manager request handling for allowing AI tools in the task execution process. - Updated TaskExecutionRequested and TaskExecutionApproved payloads to include flags for explicit manager requests and human-approved executions. - Added new service functions to manage suggest-only execution gate logic, allowing for exceptions based on explicit approvals. - Enhanced the WorkSuggestion components to support requesting task execution approvals separately from accepting suggestions. - Updated API endpoints and utility functions to accommodate new approval workflows and improved error handling. - Added comprehensive tests for new functionalities, ensuring robust coverage for the approval process and suggest-only logic.
Only the Allow AI tools path may skip ingress fail-closed and bypass mode denial after human approval; generic approvals stay blocked. Co-authored-by: Cursor <cursoragent@cursor.com>
Generic approvals must not set humanApprovedExecution; only the explicit manager Allow AI tools path may. Co-authored-by: Cursor <cursoragent@cursor.com>
…very Keep human-approved suggest_only from skipping unrelated unsafe denials, copy explicitManagerRequest into the outbox payload, and recover duplicate request-execution while the action is still requested. Co-authored-by: Cursor <cursoragent@cursor.com>
d093fff to
b1bed59
Compare
1 participant
This pull request implements Phase 2.4 of the "suggest_only" execution mode, introducing explicit manager approval and human-approved re-entry paths for task execution, and enhances the Work Inbox and approvals product UI. It adds new API and UI surfaces for managing approvals, enforces granular authorization checks, and introduces robust backend logic and tests for handling suggest_only mode exceptions. The changes also improve the flexibility and security of the approvals workflow.
Suggest_only execution mode exceptions and backend logic:
shouldSkipSuggestOnlyIngressFailClosedandresolveSuggestOnlyPolicyOverridehelpers to handle explicit manager requests and human-approved re-entry as exceptions to the suggest_only fail-closed path, with comprehensive unit tests (apps/task-worker/services/suggest-only-execution-gate.ts,apps/task-worker/tests/suggest-only-execution-gate.test.ts). [1] [2]explicitManagerRequest,humanApprovedExecution) and adjusting the approval and blocking logic accordingly (apps/task-worker/index.ts). [1] [2] [3] [4] [5] [6]Approvals API and authorization:
apps/web/app/api/task-approvals/route.ts). [1] [2] [3] [4] [5]Work Inbox and approvals UI improvements:
/inboxand/inbox/approvalssurfaces in the product UI, reusing existing APIs and enabling actionable WorkSuggestion triage (accept/assign/dismiss) from the inbox (.changeset/v2-p2-inbox-ui.md,.changeset/v2-p2-approvals-product-ui.md,.changeset/v2-p2-suggestion-triage.md).useCallbackfor loading data and support new API parameters (apps/web/app/admin/task-approvals/page.tsx). [1] [2] [3]WorkSuggestion mutation and coordination task linkage:
.changeset/v2-p2-suggestion-mutations.md).Explicit manager approval and execution path:
.changeset/v2-p2-execution-approve-separate.md).Summary by CodeRabbit
New Features
Bug Fixes
Tests