fix(attachment): don't emit a pending_media skeleton on upload - #293
Conversation
attachment_upload published a `pending_media` skeleton for every uploaded image/audio/video, keyed by the new attachment id. The only thing that resolves it is attachment_send with the same id — and there is no reaper. But upload and send are separate, discretionary steps: agents routinely upload a file just to inspect it (attachment_upload → attachment_fetch) and then send a different one, or none. Every uploaded-but-unsent renderable attachment thus stranded a permanent "生成中… / generating…" bubble in the chat (the document- only guard didn't help — images/audio/video were exactly the stranding case). Make attachment_send the sole emitter. The chat consumer already handles a first-time attachment with no pre-existing placeholder, so nothing regresses on the normal upload-then-send path; we only lose a marginal skeleton during the (usually sub-second) gap between back-to-back upload and send. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (1)
Included review availability: 1 review is currently available. Your included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour. 📝 WalkthroughWalkthroughThe attachment upload tool no longer emits ChangesAttachment event flow
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The revised upload-and-send flow delivers attachments directly without requiring a placeholder event. No actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
A rabbit uploads with careful delight Comment |
Problem
attachment_uploadpublished apending_mediaskeleton for every uploaded image/audio/video, keyed by the new attachment id (apps/agent/src/tools/attachment.ts). The only thing that resolves that skeleton isattachment_sendwith the same id — and there is no reaper anywhere.But upload and send are separate, discretionary steps. Agents routinely
attachment_uploada file just to inspect it (attachment_upload→attachment_fetch) and then send a different one, or none at all. Every uploaded-but-unsent renderable attachment therefore stranded a permanent "生成中… / generating…" bubble in the chat. (The existing document-only guard didn't help — image/audio/video were exactly the stranding case.)Real-world trace: a twin asked about album covers uploaded
album_cover.pngandcard_00_cover.jpgto compare, sent onlyalbum_cover.png, and thecard_00_cover.jpgupload left a forever-"生成中…" bubble.Fix
Make
attachment_sendthe sole emitter — remove the speculativepending_mediaemit at upload time. The chat consumer already handles a first-time attachment with no pre-existing placeholder, so the normal upload→send path doesn't regress; we only lose a marginal skeleton during the (usually sub-second) gap between back-to-back upload and send.Notes
amiko createjobs whose jobId-keyed skeleton isn't resolved when the agent delivers the result viaattachment_send— tracked/fixed separately.amiko-openhermitwhich clones this repo'smain.🤖 Generated with Claude Code
Summary by CodeRabbit