llm-deepseek: a missing attachment surfaces as TRANSPORT ("DeepSeek Messages transport failed"), is retried 5x, and blocks the session

[KURISUNO4]

Issues are disabled on this repo, so posting here per README (feedback/bug reports go to Discussions).

Environment

• DSH desktop 0.2.1-rc.2 (dshBuildCommit 332895e0f7c9d4dbfb29729f5eb367fa263ff986)
• Windows 11 x64, Electron 44.7.0
• provider deepseek-official, model deepseek-flash, reasoningEffort: high
• default baseURL (https://api.deepseek.com/anthropic), no proxy, no custom endpoint

Symptom

Once a session's durable history contains an image block whose attachment blob is gone from the local content-addressed store, every subsequent request in that session fails immediately:

assistant/attempt { finish: { kind: "error", failure: { message: "DeepSeek Messages transport failed", code: "TRANSPORT" } } }
llm/retry        { retry: 1..5, maxRetries: 5, failure: { ... code: "TRANSPORT" } }
turn/end         { reason: { kind: "error", error: { message: "DeepSeek Messages transport failed", code: "TRANSPORT" } } }

• First failure lands ~80 ms after the blob disappears — no network round trip is made, so this is a local failure, not transport.
• The default retry policy (["normal", 5, ["EMPTY_RESPONSE","MALFORMED_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"], 500, 10000, 0.1]) puts TRANSPORT in the retryable set, so every step burns 5 attempts (~15–20 s) before the turn ends in error.
• It never self-heals: the dangling reference stays in history, so every later turn repeats it. The only way out is abandoning the session (or hand-editing its journal).
• The message points the user at the network, while the actual cause is "attachment object is missing". The cause carried on the LlmError never reaches llm/retry / turn/end, so the journal alone cannot distinguish this from a real socket failure.

Root cause

prepareImages() is the first statement of request():

packages/llm/llm-deepseek/src/adapter.ts:96

const { messages, versions } = await prepareImages(
  options.messages, connection, options.model, this.dependencies.resolveAttachments?.(), this.imageAccess, signal,
)

prepareImages() resolves every retained image through attachments.readImageRequest(...). When the blob $DSH_HOME/attachments/v1/objects/<h[0:2]>/<h> is absent, @deepseek-ai/dsh-attachment-local throws

AttachmentError('Attachment object is missing.', 'ATTACHMENT_NOT_FOUND')

AttachmentError extends Error, not LlmError, and generate() only preserves LlmError:

packages/llm/llm-deepseek/src/adapter.ts:76-80

} catch (error) {
  if (timeoutOf(watchdog.signal, 'MESSAGES_IDLE') !== undefined) throw new LlmError('DeepSeek Messages stream idle timeout', 'TIMEOUT', { cause: error })
  if (options.signal?.aborted) throw new LlmError('DeepSeek Messages request aborted', 'ABORTED', { cause: error })
  if (error instanceof LlmError) throw error
  throw new LlmError('DeepSeek Messages transport failed', 'TRANSPORT', { cause: error })
}

So a deterministic, purely local "attachment missing/corrupt" condition is classified as a transient transport failure and retried.

Same shape exists one layer down for the Files API: file-store.ts — throw new LlmError('DeepSeek Files API request to ${this.baseURL} failed', 'TRANSPORT', { cause: error }).

Reproduction (self-contained, no user data)

1. Start a session and get an image into it, e.g. a tool result with { "type": "image", "attachment": { "attachmentId": "sha256:<h>" } }.
2. Confirm the object exists at $DSH_HOME/attachments/v1/objects/<h[0:2]>/<h>.
3. Delete just that object file (leave the session journal untouched).
4. Send any follow-up message. Every step fails in <100 ms with TRANSPORT, 5 retries, then turn/end error.
5. Restore the exact same bytes at the same path → the session works again.

Step 5 isolates the blob as the only variable: nothing about credentials, network, model or journal changed.

Expected

• A non-retryable, self-describing error, e.g. code: "ATTACHMENT_NOT_FOUND" with a message naming the attachment id, surfaced in the transcript as such.
• Optionally, a UI affordance on resume: "N images in this conversation are no longer available" with an action to drop/placeholder them from history (the alternative today is abandoning the session).

Suggested fix (minimal)

In generate()'s catch, before the catch-all wrap:

if (isAttachmentError(error)) throw new LlmError(`Image attachment unavailable: ${error.message}`, error.code, { cause: error })

and keep that code out of the retry policy (it is deterministic). Consider also surfacing cause.message on llm/retry / turn/end, so an attachment failure is not indistinguishable from a socket failure in the session journal.

Impact

Anyone who cleans, restores, syncs, or partially loses $DSH_HOME/attachments (a privacy-motivated cleanup of locally generated images is an obvious case) permanently loses the ability to continue those conversations, and is told the network is broken.

[Muguett-DBY]

If there is a completed turn before the first missing image, you can recover the earlier context using the existing message-level branch action:

1. Find the last assistant reply of a completed turn before that image entered the conversation.
2. Hover its footer and select Branch into a new conversation.
3. Continue in the child conversation. Copy across any later text you still need and attach fresh copies of any images.

The cut matters: the sidebar's Fork session action uses the latest completed turn, which can still include the broken attachment reference. The message action sends an explicit event position. Its button is unavailable on intermediate replies within a turn. See the message-action check.

I checked the published @deepseek-ai/dsh-session@0.2.1-rc.2 on Node 24.22.1 and 26.12.1 with synthetic history: a fork before the image derives zero image blocks; a fork including it retains the reference. Appending to the child leaves the source unchanged. This was a SessionStore check, without a desktop launch or provider request; the rc.2 UI bundle also contains the message-level action.

Only the selected prefix carries over. The original conversation remains available, but this cannot restore the missing bytes. If the image was in the first turn, there may be no usable earlier branch point. The error classification still needs fixing.

_{AI-assisted; package behavior checked locally.}