[bug] agent does not deliver reply despite successful trace with full response

[mrgoonie]

[bug] Agent does not deliver reply even though trace completed successfully with full response

Context

Gateway server: goclaw.zuey.me

Trace ID: 019eb250-68bc-7e1d-9a9d-ec4a2193b145

Reporter observed a run where the trace shows the agent session completed successfully and contains a full response, but the end user did not receive any visible reply in the chat channel.

This looks like a delivery-layer failure after successful agent execution, not a model/tool execution failure.

Actual behavior

• User sends a message to the agent through the gateway/channel
• Trace reports the session/run ended successfully
• Trace contains the assistant response content
• No final answer is delivered back to the user in the active chat channel

Expected behavior

If an agent run completes successfully and has a final assistant response, the gateway should deliver that response to the originating channel/chat.

If delivery is skipped or fails, the trace should clearly expose why, for example:

• channel delivery disabled
• streaming placeholder/finalization failed
• outbound bus publish failed
• channel adapter send failed
• message suppressed by delivery behavior/block reply state
• missing routing metadata/chat ID/message ID
• provider/channel timeout

Impact

This is a high-severity UX bug because the agent appears to have completed work internally, but the user sees no answer. It is especially hard to debug because the trace can look successful from the agent/session perspective while the actual channel delivery failed or was suppressed.

Known details

• Gateway: goclaw.zuey.me
• Trace ID: 019eb250-68bc-7e1d-9a9d-ec4a2193b145
• The trace reportedly has a complete response
• The session reportedly ended successfully
• User-visible reply was missing

Suspected area

Likely around the boundary between agent completion and channel delivery:

• internal/channels/events.go
• internal/channels/runs.go
• streaming finalization / placeholder update path
• outbound bus publish path
• Telegram/channel adapter delivery path
• delivery behavior state such as blockReplySent, ackCancelled, interimDelivered, streaming, or final reply suppression

Recent related changes that may be worth checking:

• 50c8519f fix(channels): require generated delivery replies
• fe705ef4 fix(ui): use provider model selectors for delivery behavior
• fdba1c21 feat(channels): add sidecar delivery behavior overrides
• 23b18fa6 fix(channels): rely on generated intermediate progress (#143)
• 391b6c68 fix(telegram): show tool status without placeholder (#139)

Suggested investigation

1. Load trace 019eb250-68bc-7e1d-9a9d-ec4a2193b145 on goclaw.zuey.me
2. Confirm the agent final response span/content exists
3. Check whether a final outbound message event was emitted after run completion
4. Check channel routing metadata for the run: channel name, chat ID, message ID, reply target, tenant ID
5. Check whether streaming finalization or placeholder update failed silently
6. Check whether blockReplySent / ackCancelled / delivery behavior state prevented final delivery
7. Check gateway logs around the trace timestamp for channel adapter send errors
8. If final delivery failed, ensure the trace records a delivery failure span/event instead of showing only successful agent completion

Acceptance criteria

• A completed run with final assistant response always attempts final channel delivery
• If delivery succeeds, the user receives the response
• If delivery fails or is intentionally skipped, the trace shows an explicit delivery status and reason
• Regression test covers: successful agent response + channel delivery failure/suppression should not appear as a fully successful user-visible run

Extra note

This bug may be related to the newer delivery behavior / quick acknowledgement / intermediate reply logic. Please check whether generated progress or block reply state can accidentally suppress the final response while the run itself still completes successfully.