Skip to content

fix(attachment): don't emit a pending_media skeleton on upload - #293

Merged
williamwa merged 1 commit into
mainfrom
fix/no-pending-media-skeleton-on-upload
Sep 22, 2026
Merged

williamwa merged 1 commit into
mainfrom
fix/no-pending-media-skeleton-on-upload

Conversation

@williamwa

@williamwa williamwa commented Sep 18, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

attachment_upload published a pending_media skeleton 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 is attachment_send with the same id — and there is no reaper anywhere.

But upload and send are separate, discretionary steps. Agents routinely attachment_upload a 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.png and card_00_cover.jpg to compare, sent only album_cover.png, and the card_00_cover.jpg upload left a forever-"生成中…" bubble.

Fix

Make attachment_send the sole emitter — remove the speculative pending_media emit 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

  • Scope: this fixes the attachment_upload orphan source. A separate, larger orphan source exists — amiko create jobs whose jobId-keyed skeleton isn't resolved when the agent delivers the result via attachment_send — tracked/fixed separately.
  • Deployed via amiko-openhermit which clones this repo's main.

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes
    • Renderable media uploads no longer emit premature pending-media events.
    • Media upload and sending are now handled as separate operations, with send events emitted only when media is sent.

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>
@coderabbitai

coderabbitai Bot commented Sep 18, 2026 •

Copy link
Copy Markdown

Review Change StackReview Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Essentials

Run ID: 952f0139-ab4d-4a7f-9cb4-5659d3ad260c

📥 Commits

Reviewing files that changed from the base of the PR and between 1bee796 and 2c80a3a.

📒 Files selected for processing (1)
  • apps/agent/src/tools/attachment.ts

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.


📝 Walkthrough

Walkthrough

The attachment upload tool no longer emits pending_media events or creates media placeholders. The attachment_send operation remains responsible for emitting attachment events.

Changes

Attachment event flow

Layer / File(s) Summary
Remove upload-time pending media emission
apps/agent/src/tools/attachment.ts
The upload tool no longer classifies uploaded media, creates placeholders, or publishes pending_media events. attachment_send remains the event emitter.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 2c80a

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)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly states the main change: prevent attachment uploads from emitting a speculative pending_media skeleton.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

A rabbit uploads with careful delight
No pending placeholder appears in sight
The sender now carries the event
Each attachment follows its intent
Clean paths lead through the moonlit night

Comment @coderabbitai help to get the list of available commands.

@williamwa
williamwa merged commit 9b3108f into main Sep 22, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant