fix(session): server always generates message ID, store client-provided ID as clientMessageID

[klly14]

Issue for this PR

Closes #11869

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When a caller passes a custom `messageID` to `prompt`, OpenCode used it directly:

id: input.messageID ?? MessageID.ascending(),

Passing an ID takes a different async code path than the no-ID case. With openai-compatible providers like LiteLLM, streaming starts fast enough that by the time the stream processor attaches, the first `text-start` chunk has already come and gone. The Vercel AI SDK tracks text parts by ID in `activeTextContent` — `text-start` registers the entry, `text-delta` looks it up. If `text-start` is dropped because the processor wasn't ready yet, `text-delta` finds nothing and throws:

text part chatcmpl-xxx not found

The no-`messageID` path doesn't hit this because it's synchronous — the processor is always attached before LiteLLM sends anything.

I looked at whether an `await` could fix it. `createUserMessage` is already awaited before the loop. The race is inside `streamText`'s `eventProcessor` TransformStream, which is internal to the AI SDK — there's nowhere in OpenCode's code to insert an await that reliably closes the window.

The fix: always generate the ID server-side, store whatever the caller sent as `clientMessageID`:

// Before
id: input.messageID ?? MessageID.ascending(),

// After
id: MessageID.ascending(),
clientMessageID: input.messageID,

One code path now. Processor always attaches before streaming starts. Callers can still correlate their ID via `clientMessageID` on the `message.updated` SSE event. This also fixes the clock skew stall from #24476 / #25024 as a side effect — client-generated IDs can arrive out of order when clocks differ.

How did you verify your code works?

Added three tests to `test/session/prompt.test.ts`:

• When `messageID` is passed, the stored message gets a server-generated `id`, not the caller's value
• The caller's value is saved as `clientMessageID`
• The assistant's `parentID` references the server-generated `id`
• When no `messageID` is passed, `clientMessageID` is `undefined`

All pass. There's one pre-existing timeout failure in the suite unrelated to this change.

Screenshots / recordings

N/A — not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found a related PR:

Related PR:

• fix: server-generated message IDs to prevent client/server clock skew #11869 - "fix: server-generated message IDs to prevent client/server clock skew"
  • fix: server-generated message IDs to prevent client/server clock skew #11869
  • This is directly mentioned in the PR description as addressing the same underlying issue. PR fix(session): server always generates message ID, store client-provided ID as clientMessageID #26079 appears to be a more comprehensive fix that builds upon or replaces the approach in fix: server-generated message IDs to prevent client/server clock skew #11869.

The current PR (#26079) explicitly states it "Closes the same underlying issue as #11869," so this is an intentional follow-up rather than a true duplicate. However, if #11869 is still open, there may be overlapping changes.

No other significant duplicate PRs were found addressing the same messageID handling problem.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍