Bug: Responses API completed-empty payload is retried as empty response after a successful tool call

[eeee0717]

Summary

When using Bub with Telegram and an OpenAI model over the Responses API path, a turn can fail after a successful tool call because a completed response with no extracted text/tool calls is treated as empty response, retried 4 times, and then surfaced to the user as:

An error occurred at stage 'turn': temporary: openai:gpt-5.4-pro: LLM call failed after retries

This was observed on March 11, 2026.

Environment

• bub: 0.3.0a1
• republic: 0.5.4
• channel: Telegram
• model: openai:gpt-5.4-pro
• transport: responses (from Bub payload logging)
• deployment: Docker

Steps To Reproduce

1. Start Bub with Telegram enabled.
2. Send a simple Telegram message such as h.
3. Let the agent respond through the Telegram skill/tool path.
4. After the tool call succeeds, Bub starts the next loop step.
5. The provider returns a Responses payload that appears to be completed, but Bub retries it as empty response until the turn fails.

Actual Behavior

• The tool call succeeds.
• Bub logs openai:gpt-5.4-pro: empty response 4 times.
• The turn ends with temporary: openai:gpt-5.4-pro: LLM call failed after retries.
• Bub dispatches an error message back to the Telegram chat.

Expected Behavior

• A completed Responses payload with status=completed and incomplete_details=null should not be retried as an error in this case.

Sanitized Log Excerpt

2026-03-11 11:42:01 INFO  session.message received active session_id=telegram:<chat_id>
content={"message":"h","message_id":<redacted>,"type":"text","username":"<redacted>","full_name":"<redacted>","sender_id":"<user_id>","sender_is_bot":false,"date":<redacted>}

2026-03-11 11:42:02 INFO  loop.step step=1 tape=<tape_id> model=openai:gpt-5.4-pro

2026-03-11 11:42:07 INFO  tool.call.start name=bash cmd="uv run /app/src/bub_skills/telegram/scripts/telegram_send.py --chat-id <chat_id> --message '<redacted>' ..."
2026-03-11 11:42:13 INFO  tool.call.success name=bash elapsed_time=6154.95ms

2026-03-11 11:42:13 INFO  loop.step step=2 tape=<tape_id> model=openai:gpt-5.4-pro

[openai:gpt-5.4-pro] attempt 1/4 failed: [temporary] openai:gpt-5.4-pro: empty response
WARNING llm.empty_response_payload provider=openai model=gpt-5.4-pro transport=responses payload_type=ResponseResource payload={"id":"<response_id>","object":"response","status":"completed","incomplete_details":null,"model":"gpt-5.4-pro",...}

[openai:gpt-5.4-pro] attempt 2/4 failed: [temporary] openai:gpt-5.4-pro: empty response
WARNING llm.empty_response_payload provider=openai model=gpt-5.4-pro transport=responses payload_type=ResponseResource payload={"id":"<response_id>","object":"response","status":"completed","incomplete_details":null,"model":"gpt-5.4-pro",...}

[openai:gpt-5.4-pro] attempt 3/4 failed: [temporary] openai:gpt-5.4-pro: empty response
WARNING llm.empty_response_payload provider=openai model=gpt-5.4-pro transport=responses payload_type=ResponseResource payload={"id":"<response_id>","object":"response","status":"completed","incomplete_details":null,"model":"gpt-5.4-pro",...}

[openai:gpt-5.4-pro] attempt 4/4 failed: [temporary] openai:gpt-5.4-pro: empty response
WARNING llm.empty_response_payload provider=openai model=gpt-5.4-pro transport=responses payload_type=ResponseResource payload={"id":"<response_id>","object":"response","status":"completed","incomplete_details":null,"model":"gpt-5.4-pro",...}

2026-03-11 11:42:24 INFO  session.run.outbound session_id=telegram:<chat_id>
content=An error occurred at stage 'turn': temporary: openai:gpt-5.4-pro: LLM call failed after retries

Notes

From the logged payload shape, this looks like a completed Responses API payload rather than an incomplete/failed one.

[eeee0717]

I re-tested this after the Republic-side fix in bubbuild/republic#30, and the original issue is still reproducible in Bub, but with a different payload shape.

republic#30 appears to have fixed the completed + metadata-only output case (reasoning / compaction), but the Bub turn can still fail after a successful channel-delivery tool call when the follow-up Responses call returns a completed assistant message with empty text.

What I re-confirmed

1. The channel delivery itself succeeds before the error

In the real Telegram flow, Bub successfully executes the delivery tool/script first. The tape shows:

• a successful channel-delivery tool call
• a successful tool result such as Message sent successfully ...
• then Bub starts another loop step with the prompt:
  Continue the task or respond to the channel...

So the turn is not failing before delivery. The user-visible reply has already been sent successfully.

2. Bub still unconditionally continues after any tool_result

This seems to be the Bub-side control-flow problem.

Bub currently treats any tool_calls / tool_results as continue, which means that after a successful channel-delivery tool result it still forces another model turn, even though the user-facing delivery is already complete.

That extra follow-up turn is where the failure happens.

3. The new failing payload is not metadata-only

I captured the follow-up Responses payload from the failing turn. Sanitized summary:

• transport: responses
• status: completed
• incomplete_details: null
• output length: 1
• output item types: ["message"]
• extracted text: ""
• extracted tool calls: []

In other words, the provider returned a completed assistant message, but the message content was empty.

This is different from the case handled by republic#30, which was specifically about completed metadata-only outputs such as reasoning / compaction.

4. This is reproducible on more than one OpenAI-compatible gateway

I reproduced the same pattern on multiple sanitized OpenAI-compatible gateways / model routes:

• simple one-shot chat works (Reply with exactly READY succeeds)
• the failure only appears on the Bub follow-up turn that happens after a successful channel-delivery tool result
• that follow-up turn retries empty response 4 times and then surfaces:
  temporary: <model>: LLM call failed after retries

So this no longer looks like a single-gateway quirk.

Sanitized reproduction

1. Run Bub with:
   • a Telegram channel
   • an OpenAI-compatible gpt-5.x model
   • responses transport
2. Send a short Telegram message such as hi / 你好
3. Let Bub respond through the channel-delivery tool path
4. Observe:
   • delivery tool succeeds
   • Bub starts another loop step with Continue the task or respond to the channel...
   • the follow-up Responses call returns a completed-but-empty assistant message
   • Republic retries it as empty response
   • Bub ends the turn with a user-visible error

Why the issue is still not fully resolved

My current understanding is:

• republic#30 was necessary and fixed one class of completed-empty payloads
• but Bub still has a control-flow problem:
  a successful channel-delivery tool result is not treated as a terminal condition
• this means Bub keeps asking the model to continue even when the user-facing work is already done
• some gpt-5.x Responses providers/models answer that no-op follow-up with a completed empty assistant message
• that payload shape is still retried as empty response, which eventually becomes the turn error

Suggested direction

I think this now needs a Bub-side fix, not only a Republic-side fix.

A likely direction would be to add an explicit terminal signal for successful delivery, instead of treating all tool_result values as continue. For example, a channel-delivery tool could return something like:

{
  "_bub": {
    "final": true,
    "kind": "delivery"
  }
}

Then Bub could stop the turn after successful user-facing delivery, instead of forcing another Continue... step.

That would make the behavior channel-agnostic and would avoid depending on provider-specific behavior for a no-op follow-up turn.

[PsiACE]

To be honest, I tried switching to a few different models but couldn’t reproduce the issue on main . I’m not sure what the exact environment and conditions are for reproducing it.

[PsiACE]

hi @eeee0717 Could you try the latest main branch? I think if this is a known issue with max steps, it might be related to the tool; we also introduced a new fix yesterday. #118

[eeee0717]

fixed!