Observed (PR #468, 2026-07-23)
Two identical uploads-sh[bot] 📎 Attachments comments were posted (ids 5061168298 / 5061168332, both created 17:02:25Z), and a later uploads meta set on the PR-keyed object did not refresh either comment.
1. Create race → duplicate comment
upsertBotComment (apps/api/src/github-comment.ts) is hunt-then-create with no idempotency guard: KV cached-id → marker hunt → POST when nothing is found. On PR #468 two callers ran concurrently — the GitHub App webhook (PR opened at 17:02:24, queued promote + comment) and a CLI uploads attach --pr 468 moments later. Both hunted while the thread had no marker, both POSTed. Consecutive comment ids in the same second confirm the race.
Aggravating factor: the KV comment-id cache is written after create (last-writer-wins) and the marker hunt stops at the first match, so one duplicate becomes permanently unreachable — every future sync PATCHes the winner and the loser drifts stale forever. The issue_comment self-heal (#325-era) doesn't help; it recreates missing comments, it doesn't collapse extras.
Proposed fix — self-healing dedupe rather than a lock: when the marker hunt finds more than one marker comment, PATCH the oldest and DELETE the rest. That heals existing duplicates on every subsequent sync and makes the create race retroactively harmless. A CAS-style lock on create would only narrow the window; dedupe closes it.
2. meta set doesn't refresh the comment
Comment sync runs only from attach/comment/promote (github-comment-service.ts) and the webhook. uploads meta set writes D1 and stops, so display-relevant metadata added after upload (e.g. backfilling path= or changing state=) never reaches the rendered comment until some unrelated attach happens. Since #370 renders path/state in the comment, meta set on a gh/…-keyed object should either trigger the same sync attach does, or at minimum print the established-style stderr hint: tip: run uploads comment to refresh the PR comment.
Repro sketch for (1)
Repo with the App installed; from a branch with staged attachments, gh pr create and immediately uploads attach <file> --pr <new-pr>. Webhook and CLI race the first comment creation.
Observed (PR #468, 2026-07-23)
Two identical
uploads-sh[bot]📎 Attachments comments were posted (ids 5061168298 / 5061168332, both created 17:02:25Z), and a lateruploads meta seton the PR-keyed object did not refresh either comment.1. Create race → duplicate comment
upsertBotComment(apps/api/src/github-comment.ts) is hunt-then-create with no idempotency guard: KV cached-id → marker hunt → POST when nothing is found. On PR #468 two callers ran concurrently — the GitHub App webhook (PRopenedat 17:02:24, queued promote + comment) and a CLIuploads attach --pr 468moments later. Both hunted while the thread had no marker, both POSTed. Consecutive comment ids in the same second confirm the race.Aggravating factor: the KV comment-id cache is written after create (last-writer-wins) and the marker hunt stops at the first match, so one duplicate becomes permanently unreachable — every future sync PATCHes the winner and the loser drifts stale forever. The
issue_commentself-heal (#325-era) doesn't help; it recreates missing comments, it doesn't collapse extras.Proposed fix — self-healing dedupe rather than a lock: when the marker hunt finds more than one marker comment, PATCH the oldest and DELETE the rest. That heals existing duplicates on every subsequent sync and makes the create race retroactively harmless. A CAS-style lock on create would only narrow the window; dedupe closes it.
2.
meta setdoesn't refresh the commentComment sync runs only from attach/comment/promote (
github-comment-service.ts) and the webhook.uploads meta setwrites D1 and stops, so display-relevant metadata added after upload (e.g. backfillingpath=or changingstate=) never reaches the rendered comment until some unrelated attach happens. Since #370 renders path/state in the comment,meta seton agh/…-keyed object should either trigger the same sync attach does, or at minimum print the established-style stderr hint:tip: run uploads comment to refresh the PR comment.Repro sketch for (1)
Repo with the App installed; from a branch with staged attachments,
gh pr createand immediatelyuploads attach <file> --pr <new-pr>. Webhook and CLI race the first comment creation.