[Bug] OpenAI Responses final item completes but missing response.completed hangs until idle timeout

[xiangyuliu]

Summary

A third-party OpenAI Responses-compatible gateway can complete a final answer
item but omit response.completed and keep the SSE connection open. DSH has the
complete answer text, yet waits until the 300-second stream idle timeout and
then marks the turn failed.

Environment

• macOS 26.6.1 (25G76)
• Node.js 24.19.0
• @deepseek-ai/dsh@0.1.5-rc.1
• @deepseek-ai/dsh-llm-pi-ai@0.1.5-rc.1
• @earendil-works/pi-ai@0.85.1
• custom GPT-family model through llm-pi-ai / openai-responses

Sanitized event sequence

response.output_item.added       item.type=message
response.output_text.delta       ...complete answer text...
response.output_item.done        item.type=message, phase=final_answer
# no response.completed / response.failed / response.incomplete
# connection remains open and may emit keep-alives

Actual behavior

• The full final answer is visible in the received stream.
• No terminal response event arrives.
• After about 300 seconds, the attempt fails with
  pi-ai stream idle timeout after 300000ms.
• Retry may repeat the same long wait and discard an otherwise complete answer.

Expected behavior

DSH should offer a bounded, explicit compatibility path for providers that
finish a phase=final_answer message item but omit the response-level terminal
event. Strict behavior can remain the default if accepting the item-level
terminal signal globally is considered too permissive.

Locally validated compatibility behavior

After response.output_item.done for a message whose phase is final_answer:

1. wait a short grace period for a conforming response-level terminal event;
2. if it arrives, use it and preserve its usage/status;
3. if it does not arrive, abort the hanging read and finish from the completed
   item with an explicit compatibility stop reason;
4. do not apply this fallback to partial messages or tool-call items.

A 2-second local grace period passed both regression paths: normal
response.completed preserved usage, while a deliberately hanging source
ended locally after the completed final item. I am not proposing that 2 seconds
must be the global default; a provider-level option such as
terminalEventGraceMs would make the trade-off explicit. When fallback is used,
response-level usage may be unavailable and should not be fabricated.

[zhiyuchen1101]

Independent reproduction on a different adapter, which may matter for where
the fix belongs:

llm-deepseek (chat-completions protocol, deepseek-official /
deepseek-v4-flash, baseURL: https://api.deepseek.com/beta) shows the same
class of failure without any OpenAI-compatible gateway in the path. The
assistant payload is fully delivered — reasoning (1560 chunks) and tool calls
(1169 chunks) — and then the connection never terminates, no finish event
arrives, and the attempt dies on the idle watchdog. Three consecutive attempts
lost 10.0 / 17.3 / 17.7 minutes this way; the user waited ~59 minutes with no
output.

One detail your report does not mention, which I think is a separate defect
worth fixing on its own: the failure reads stream idle timeout after 300000ms,
but the actual wait was up to 17.7 minutes. idleWatchdog.pulse() re-arms the
timer rather than accumulating, and onActivity fires on every SSE comment
line, so keep-alive traffic resets the timer indefinitely. Raising
streamIdleTimeoutMs only makes the failure later; lowering it does not help
while keep-alives arrive faster than the threshold. An absolute per-attempt
ceiling would bound this independently of any provider-terminal-event grace
path.

Details and the raw event sequence: #6959