Opus finding
comment_already_posted fast-path skips finding_status lifecycle recovery
mediumdata-losshigh
- apps/web/lib/review-worker.ts:124-133
The comment says 'a prior attempt posted the comment but didn't finish settling the status'. But the prCommentId is set by setReviewComment, which runs INSIDE the try/catch that also writes finding_status — if setReviewComment succeeded then recordFindingStatuses may or may not have. If recordFindingStatuses threw (the catch only logs), prCommentId is set but finding_status rows are missing. The retry now sees prCommentId != null and immediately marks the row done without ever attempting to recover the finding_status rows. Sweeper will then have no lifecycle rows to reconcile for this review — silently losing the close-detection capability. This is a real (though narrow) data-loss path.
Recommendation
Either (a) before the fast-path, query finding_status by reviewId; if empty, fall through to recordFindingStatuses recovery, or (b) move setReviewComment AFTER recordFindingStatuses so prCommentId being set implies lifecycle is also persisted. Option (b) is simpler and aligns the invariant the comment claims.