fix: treat "other" as a continue stop reason

[kkugot]

Issue for this PR

Closes #20465

Type of change

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

What does this PR do?

Fixes blank assistant text in TUI when MCP servers are enabled, a regression introduced in v1.3.4 by the AI SDK 5 -> 6 upgrade.

Root cause: The v6 finish-reason adapter changed the default unmapped reason from unknown to other. The prompt loop continue sets in prompt.ts had unknown removed but other was never added as a replacement. This causes the loop to exit after MCP tool calls before the model produces final text. MCP amplifies this because tool-enabled requests hit this code path far more often.

Additional fix: The TUI AssistantMessage component rendered empty space for intermediate assistant messages whose parts were all hidden (completed tools with details off, empty text). Added a reactive visible memo that hides the entire message when no parts would render.

How did you verify your code works?

• Tested locally with MCP enabled: assistant text renders correctly, symptom gone
• Tested with MCP disabled: no behavior change
• bun typecheck — no new errors (only pre-existing ripgrep.ts errors on dev)

Checklist

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

[github-actions]

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

Potential Related PRs Found:

1. PR fix(opencode): run transformParams middleware unconditionally for all call types #19558 - "fix(opencode): run transformParams middleware unconditionally for all call types"

   • fix(opencode): run transformParams middleware unconditionally for all call types #19558
   • Why related: This PR addresses middleware execution issues with request transformation, similar to the LLM middleware fix in the current PR that handles v6 request param shapes (messages, input, prompt).

2. PR fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers #14973 - "fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers"

   • fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers #14973
   • Why related: This PR addresses the prompt loop exit issue after tool calls, which relates to the finish-reason mapping changes in the current PR.

[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. 👍

[kkugot]

I am keeping this branch up-to date with dev, would be thankful if this can be merged. engineers using Oracle Code Assist could not use opencode with Open AI models with responses API because of this bug. This is since version 1.3.4

[rekram1-node]

@kkugot let me look over this

[rekram1-node]

The LLM middleware in llm.ts targeted args.params.prompt for applying ProviderTransform.message(), but v6 Responses requests use messages or input. This meant message normalization was silently skipped on Responses requests.

Im not sure this is accurate

[kkugot]

this pr has so many unrelated changes, i thought it'd be a 2 line pr?

Ready for your review

[rekram1-node]

Alr thanks, ill double check this logic tmr I just need to make sure failure cases dont infinitely loop from this (its almost 1am here rn so too late for me to merge if im not 100% confident)

[kkugot]

@rekram1-node no pressure here, if I can help with tesing this - let me know.

[kkugot]

@rekram1-node I have checked with the recent code changes on dev and we are able to reproduce this issue only when any of the MCPs are enabled. With the proposed fix everything works correctly.

[pedantilva]

Hi @rekram1-node any idea when this will be merged? This is driving people out of OpenCode tool due to this issue.

[rekram1-node]

/review

[rekram1-node]

This was tested and works? Im just noticing that the only test seems to assert other as a stop reason to stop rather than continue which i would have assumed was not ur intent?

[kkugot]

Our provider emits OpenAI Responses-style structural completion events, but not enough SDK-friendly finish classification for opencode’s current parser. OpenAI Responses itself does not require finish_reason; the client must derive a finish classification from the event stream. The change in this PR works because it treats the unmapped completed function-call step as "other" instead of leaving it undefined.

[kkugot]

To the OCA users of opencode:
I found an OCA upstream Responses streaming issue while debugging OpenCode visibility failures. For some /v1/responses stream=true post-tool requests, upstream returns HTTP 200 but then closes the SSE stream with no useful output, sometimes only lifecycle events or even bytes:0. This happens intermittently across endpoints, so it does not look like a single bad endpoint or issue with opencode. The workaround in this PR was forcing opencode to do a retry. I added OCA proxy-side protection to hide those broken attempts from the client and retry before committing downstream SSE, which resolved the OpenCode rendering issue in my local testing. We need to bring this issue to OCA team now.