Deleting an attachment object permanently bricks the session (ATTACHMENT_NOT_FOUND is not degraded)

[qwertwery]

Environment

• @deepseek-ai/dsh 0.2.0-rc.2
• Android 15 (arm64 device, API 35)
• Node v24+
• Provider: deepseek-official / deepseek-flash

Summary

If an attachment object is removed from the local attachment store
($DSH_HOME/attachments/v1/objects/<xx>/<sha256>) while a session still
references it, that session becomes permanently unusable: every subsequent
message fails with Attachment object is missing. and no recovery is possible
without manually editing the session log.

Steps to reproduce

1. Send an image in a session, so the session log records an image block:

   {"type":"image","attachment":{"attachmentId":"sha256:<hash>","mediaType":"image/jpeg",...}}

2. Delete the backing file:

   rm "$DSH_HOME/attachments/v1/objects/<xx>/<hash>"

3. Send any new message in the same session.

Actual behavior

Every turn fails:

turn/end reason = { kind: "error", error: { message: "Attachment object is missing." } }

The session cannot be recovered. Turn N failed, and turns N+1, N+2 ... all fail
the same way, because every request replays the full history including the
dangling reference.

Expected behavior

A missing attachment should degrade gracefully: skip that image (or substitute a
text placeholder) and deliver the rest of the conversation. Losing one cached
image should not make a session unusable.

Root cause

@deepseek-ai/dsh-attachment-local/lib/index.js:610 (and :746 for file
attachments) throws unconditionally on ENOENT:

if (error instanceof Error && "code" in error && error.code === "ENOENT")
    throw new AttachmentError("Attachment object is missing.", "ATTACHMENT_NOT_FOUND");

There is no degradation anywhere up the stack. Additionally ATTACHMENT_NOT_FOUND
is not in the default retryableCodes
(EMPTY_RESPONSE / RATE_LIMIT / SERVER / TIMEOUT / TRANSPORT), so the
failure is immediate and never retried — while the UI surfaces it as
DeepSeek Messages transport failed, which is misleading (it looks like a
network problem).

Suggested fix

Catch ATTACHMENT_NOT_FOUND at request-projection time and drop the unreadable
image block for that request only. Verified locally on both providers:

dsh-llm-deepseek — prepareImages (~L1417)

for (const message of messages) for (const ref of imageRefs(message.content)) {
    if (versions.has(ref.attachmentId)) continue;
    try {
        versions.set(ref.attachmentId, await attachments.readImageRequest(ref, resolveRequestImageTarget(model, ref), signal));
    } catch (error) {
        signal?.throwIfAborted();
        if (error?.code !== "ATTACHMENT_NOT_FOUND") throw error;
    }
}
// Then drop the unreadable image blocks from this request, otherwise
// assertImagesFit / prepareFileIds read `versions.get(id).bytes` and crash.
for (const [index, message] of messages.entries()) {
    if (!Array.isArray(message.content)) continue;
    if (!message.content.some((block) => block.type === "image" && !versions.has(block.attachment.attachmentId))) continue;
    const kept = message.content.filter((block) => block.type !== "image" || versions.has(block.attachment.attachmentId));
    messages[index] = { ...message, content: kept.length === 0 ? [{ type: "text", text: "[attachment missing]" }] : kept };
}

dsh-llm-pi-ai — prepareRequestImages / userContent / budget lookup

The same idea, three sites:

• prepareRequestImages: replace the Promise.all(...) with per-ref try/catch, keeping only successfully read versions in the map;
• userContent (case "image"): when requestImages.get(id) is undefined, push a text placeholder instead of touching version.data;
• the requiredImageOffload callback: requestImages.get(id)?.bytes ?? 0.

Notes

• Verified with node --check and a real import() of both modules.
• Verified end-to-end: after the patch, deleting images that the current session
  is actively referencing no longer breaks the conversation.
• Also worth considering: marking such attachments as "offloaded" in the session
  projection so history replay does not attempt the read again at all.

[TheStreamCode]

Reproduced on 0.2.1-rc.2 through a second adapter, and the trigger was an ordinary cleanup tool call

DSH Desktop	44.7.0, Windows 11 x64, Web GUI
Bundled packages	0.2.1-rc.2
Source	687f282e (dsh-v0.2.1-rc.2, 2026-10-17)
Route	opencode-go / deepseek-v4.1-flash via @deepseek-ai/dsh-llm-pi-ai (api: openai-completions)

The failure class depends on the adapter

Most reports here have the deepseek-official shape: the AttachmentError is rewritten by the catch-all at packages/llm/llm-deepseek/src/adapter.ts:80 into TRANSPORT (retryable, looks like a network fault). On a pi-ai route the same missing object takes a different path:

• prepareRequestImages() in packages/llm/llm-pi-ai/src/context.ts:111 reads every retained reference with a bare Promise.all(...), so the raw AttachmentError escapes;
• at the adapter boundary normalizeLlmFailure() / harnessErrorCode() (packages/llm/llm/src/adapter-failure.ts:106) trust only HarnessError codes, so the terminal failure becomes { message: "Attachment object is missing.", code: "UNKNOWN" }.

Observed in the session log — later text-only turns fail identically, and there is no llm/retry event because UNKNOWN is not in the default retryable set (packages/llm/llm/src/retry-policy.ts:18):

{"type":"assistant/attempt","seq":3568,"data":{"turn":37,"step":1,"stream":[{"type":"chunk","chunk":{"type":"finish","reason":{"kind":"error","failure":{"message":"Attachment object is missing.","code":"UNKNOWN"}}}}]}}
{"type":"turn/end","seq":3570,"data":{"turn":37,"reason":{"kind":"error","error":{"message":"Attachment object is missing.","code":"UNKNOWN"}}}}

Same local condition, two different wrong classifications: TRANSPORT on dsh-llm-deepseek, UNKNOWN on dsh-llm-pi-ai. An adapter-local fix has to be written twice and still makes replay depend on adapter state; that is exactly what the shared-projection ownership in .agents/notes/proposed/bug-fix/2026-08-20-attachment-read-quarantine.md rules out.

The trigger was a normal cleanup tool call

The session history contained a user-uploaded photo (sha256:d66d8f80…fce5, 736×1104 JPEG, 118,284 bytes). Later the user asked the agent to delete the generated media and the source photo; the agent removed the attachment object with an ordinary shell tool call, because nothing in DSH labels $DSH_HOME/attachments/v1/objects/ as internal session-durable state:

deleted <DSH_HOME>\attachments\v1\objects\d6\d66d8f80…fce5    (seq 3557, same turn)

The next step of that turn failed, then every subsequent turn failed the same way, including text-only ones. The UI shows This turn failed with the message above.

Recovery worked only out-of-band — and it proves the store contract

A byte-identical copy of the upload was still on disk; its SHA-256 matched the attachment id exactly. Copying it back to objects/d6/<sha256> made the session usable on the next message (all 32 attachment references in that log resolve again; a scan over the 87 session logs stored on this machine found this single dangling reference). Session usability is a function of those exact bytes being present — durable content-addressed state, not a cache.

Updates for the existing threads

• The adapted diff in [Bug] 删除附件对象后会话每个请求都失败，并被误报为 "DeepSeek Messages transport failed"（附修复补丁） #7834 still applies cleanly at 687f282 (git apply --check passes; 4 files, +153/−7), so the stop-gap can be rebased — but it only patches dsh-llm-deepseek. The pi-ai route above is unprotected.
• The quarantine note is still Status: proposed at 687f282, and rg attachment/quarantine finds no implementation. Its acceptance criteria (durable transition, deterministic projection, restart/fork reconstruction, verified recovery) are the only shape that covers both adapters.

What I would ask for

1. Implement the quarantine note before dispatch: a durable attachment/quarantine transition, a deterministic text projection for the quarantined occurrence, no further readImage() for it, and recovery only after digest + metadata verification.
2. Until then, surface a non-retryable ATTACHMENT_NOT_FOUND from both adapters instead of TRANSPORT/UNKNOWN, naming the attachment.
3. Guard the store or offer a supported detach: the deletion here was performed by the agent itself, so a path guard (and an explicit "do not delete attachment objects" invariant) would have prevented it. A supported "detach/redact attachment in history" operation covers the legitimate case (see the credential example in [Bug] Missing attachment object still bricks image-bearing sessions on 0.2.0-rc.2, still reported as TRANSPORT (see #7582) #9262).
4. A repair affordance: verify a user-supplied copy's SHA-256 and relink it — exactly the recovery we had to perform by hand.

Question: given the note's ownership clause, would the team consider an external implementation of 2026-08-20-attachment-read-quarantine.md (against its acceptance criteria) delivered as a discussion diff/fork, even though CONTRIBUTING says external PRs are not accepted right now? I can provide the raw event trace as a minimal fixture.