-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Add manual confirmation step before approving performance bounties #2946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughUpdates the bounty completion workflow: renames the executor, changes submission status handling to submit (not approve), removes commission creation, adds owner email notifications on submission, and updates the workflow orchestrator import. Also allows performance bounties to be approved and simplifies an email template’s text. Changes
Sequence Diagram(s)sequenceDiagram
actor Partner as Partner/User
participant Web as Web App
participant WF as executeCompleteBountyWorkflow
participant DB as Database
participant Owners as Workspace Owners
participant Email as Email Service
Partner->>Web: Submit bounty for completion
Web->>WF: executeCompleteBountyWorkflow(input)
WF->>DB: Find existing submissions (submitted/approved)
alt Existing is submitted or approved
WF-->>Web: Return early with status notice
else No existing active submission
WF->>DB: Update submission where status="draft" to "submitted"
WF->>DB: Fetch program workspace owners
WF->>Email: sendBatchEmail(NewBountySubmission payload)
Email-->>WF: Ack
WF-->>Web: Success (submitted)
end
Note over Web,DB: Commission creation path removed
par Later approval
Web->>DB: Approve submission (including performance bounties)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/web/lib/actions/partners/approve-bounty-submission.ts(0 hunks)apps/web/lib/api/workflows/execute-award-bounty-workflow.ts(2 hunks)packages/email/src/templates/bounty-completed.tsx(1 hunks)
💤 Files with no reviewable changes (1)
- apps/web/lib/actions/partners/approve-bounty-submission.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-25T17:39:38.965Z
Learnt from: devkiran
PR: dubinc/dub#2736
File: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/[bountyId]/bounty-info.tsx:45-56
Timestamp: 2025-08-25T17:39:38.965Z
Learning: In the bounty system, each partner can only submit to the same bounty once. This means totalSubmissions (pending + approved + rejected) equals the number of unique partners who have submitted, making UI text like "X of Y partners completed" accurate when using totalSubmissions.
Applied to files:
apps/web/lib/api/workflows/execute-award-bounty-workflow.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (1)
packages/email/src/templates/bounty-completed.tsx (1)
63-66: Confirm commission terminology before mergingThis template now promises that “you will receive an email with the commission details.” For performance bounties, partners typically get invited to confirm the payout rather than receiving raw commission info. Please double-check with product/copy that “commission details” is the correct message before shipping; otherwise, this email may set the wrong expectation for recipients.
| // Mark the bounty as submitted | ||
| const { partner } = await prisma.bountySubmission.update({ | ||
| where: { | ||
| id: bountySubmission.id, | ||
| status: "draft", | ||
| }, | ||
| data: { | ||
| commissionId: commission.id, | ||
| status: "approved", | ||
| status: "submitted", | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid locking out manual submissions
The update guard now requires status: "draft", so any older submission already marked "submitted" or "approved" (e.g., a manually approved payout that should re-run after the new confirmation step) will fail to update and the workflow will throw a Record to update not found error. That prevents the workflow from resubmitting eligible partners.
Please drop the status predicate (or broaden it) so the update runs for pre‑existing records:
- const { partner } = await prisma.bountySubmission.update({
- where: {
- id: bountySubmission.id,
- status: "draft",
- },
- data: {
- status: "submitted",
- },
+ const { partner } = await prisma.bountySubmission.update({
+ where: { id: bountySubmission.id },
+ data: { status: "submitted" },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Mark the bounty as submitted | |
| const { partner } = await prisma.bountySubmission.update({ | |
| where: { | |
| id: bountySubmission.id, | |
| status: "draft", | |
| }, | |
| data: { | |
| commissionId: commission.id, | |
| status: "approved", | |
| status: "submitted", | |
| }, | |
| // Mark the bounty as submitted | |
| const { partner } = await prisma.bountySubmission.update({ | |
| where: { id: bountySubmission.id }, | |
| data: { status: "submitted" }, | |
| }); |
🤖 Prompt for AI Agents
In apps/web/lib/api/workflows/execute-award-bounty-workflow.ts around lines 163
to 171, the update currently restricts the WHERE clause to status: "draft",
which causes updates to fail for submissions already marked "submitted" or
"approved" and throws a "Record to update not found" error; remove the status
predicate (or broaden it to include other allowed statuses) so the update
matches the existing bountySubmission record regardless of its current status,
then set status: "submitted" in the data field as before so the record is
updated without being locked out by the previous status check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
♻️ Duplicate comments (1)
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts (1)
165-177: Remove status constraint to prevent rejected submission lock-out.The
status: "draft"constraint will cause the update to fail with "Record to update not found" if a previously rejected submission (status "rejected") now meets the performance criteria. This prevents partners from requalifying after fixing issues.The early return check (lines 92-102) only guards against "submitted" and "approved" statuses, so rejected submissions can reach this update but will fail the constraint.
Apply this diff to allow updates regardless of current status:
- const { partner } = await prisma.bountySubmission.update({ - where: { - id: bountySubmission.id, - status: "draft", - }, - data: { - status: "submitted", - }, + const { partner } = await prisma.bountySubmission.update({ + where: { id: bountySubmission.id }, + data: { status: "submitted" },
🧹 Nitpick comments (1)
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts (1)
196-232: Owner notification implementation looks good.The email notification flow correctly filters workspace owners by notification preference and sends batch emails with appropriate submission details.
The TODO comment (line 198) suggests consolidating this logic with
createBountySubmissionAction. Consider extracting a shared utility function to reduce duplication once you verify the notification flows are identical.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts(4 hunks)apps/web/lib/api/workflows/execute-workflows.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-25T17:39:38.965Z
Learnt from: devkiran
PR: dubinc/dub#2736
File: apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/bounties/[bountyId]/bounty-info.tsx:45-56
Timestamp: 2025-08-25T17:39:38.965Z
Learning: In the bounty system, each partner can only submit to the same bounty once. This means totalSubmissions (pending + approved + rejected) equals the number of unique partners who have submitted, making UI text like "X of Y partners completed" accurate when using totalSubmissions.
Applied to files:
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts
🧬 Code graph analysis (2)
apps/web/lib/api/workflows/execute-workflows.ts (1)
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts (1)
executeCompleteBountyWorkflow(13-233)
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts (3)
apps/web/lib/api/get-workspace-users.ts (1)
getWorkspaceUsers(20-91)packages/email/src/index.ts (1)
sendBatchEmail(31-67)packages/email/src/templates/bounty-new-submission.tsx (1)
NewBountySubmission(17-110)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (4)
apps/web/lib/api/workflows/execute-complete-bounty-workflow.ts (3)
3-9: LGTM!The new imports support the email notification feature for program owners and are correctly used in the implementation.
13-13: LGTM!The function rename accurately reflects the workflow change: submissions now require manual approval rather than being auto-approved.
92-102: LGTM!The updated status check correctly prevents duplicate processing for both submitted and approved bounties, with clear differentiated logging.
apps/web/lib/api/workflows/execute-workflows.ts (1)
12-12: LGTM!The import and function call correctly reflect the renamed workflow executor.
Also applies to: 77-77
Summary by CodeRabbit
New Features
Bug Fixes