Opus finding
Webhook performs synchronous LLM-pipeline-blocking work before returning 200 to GitHub
lowperformancehigh
- apps/web/app/api/github/webhook/route.ts:235-245
- apps/web/app/api/github/webhook/route.ts:222-230
GitHub considers a webhook unreachable if it does not get a 2xx within 10 seconds, after which it retries. Before returning 200 the handler performs (1) getInstallationToken (JWT mint + 1 GitHub round trip), (2) isPublicRepo + isBenchmarkRepo (2 GitHub round trips in parallel), and (3) enqueueReview (DB write). On a cold lambda or under GitHub API latency this can approach the 10s ceiling, causing GitHub to redeliver. The original webhook handler likely had the same structure, so this is pre-existing rather than introduced by this PR, but it remains a latent operational risk worth documenting. (Note: enqueueReview is idempotent, so duplicate deliveries are absorbed — but only if the deliveries also race against this same prefix consistently.)
Recommendation
Move visibility/benchmark detection inside the after() worker. Insert the review row immediately with publicReceipt=false (the safe default) and let the worker update it after fetching repo metadata. This shrinks the synchronous critical path to a single DB INSERT.