Opus finding
Comment-posted fast-path marks success but never records finding-status rows
mediumdata-lossmedium
- apps/web/lib/review-worker.ts:124-134
- apps/web/lib/review-worker.ts:232-257
setReviewComment is called BEFORE recordFindingStatuses. The fast-path triggers when prCommentId is already set — but a previous run could have set prCommentId successfully and then crashed before recordFindingStatuses inserted the finding_status rows. The fast-path then marks the review 'done' without ever creating the per-finding lifecycle rows. Because lifecycle.persist_failed is logged-and-swallowed (lines 250-262), this same-attempt failure also leaves recordFindingStatuses uncalled, but the same-attempt path at least settles the review as done by design. The cross-attempt fast-path, however, silently skips the lifecycle rows that Sweeper depends on to reconcile closure. The maintainability comment acknowledges 'losing the lifecycle row would only mean Sweeper can't reconcile closure', so the fast-path quietly perpetuates that gap rather than retrying recordFindingStatuses.
Recommendation
In the prCommentId-already-set fast-path, also attempt recordFindingStatuses (idempotently — needs an ON CONFLICT or check) before markReviewSucceeded, or at minimum log a warning so operators know lifecycle rows may be missing. Alternatively, persist finding_status BEFORE posting the comment so the lifecycle row is the durable receipt.