fix: retry transient LLM timeouts in A2A and surface error type (fixes #143)

[Longado]

Problem

_send_message_to_agent was fragile to transient LLM timeouts during long A2A tasks:

1. A single httpx.ReadTimeout anywhere in a multi-step flow (web search + tool calls) aborted the entire task immediately, discarding all progress.
2. httpx.ReadTimeout.__str__() returns "", so the UI displayed only "❌ Message send error:" — no cause, no actionable information.

Reported in #143 with full logs showing the exact failure path.

Fixes

1. Retry on ReadTimeout (exponential back-off)

Wrap llm_client.complete() in a retry loop — up to 3 attempts with 1 s → 2 s back-off before giving up:

for _attempt in range(3):
    try:
        response = await llm_client.complete(...)
        break
    except httpx.ReadTimeout:
        if _attempt == 2:
            raise
        await asyncio.sleep(2 ** _attempt)  # 1 s, then 2 s

A single transient timeout now retries silently. Only after all 3 attempts fail does the exception propagate to the outer handler.

2. Meaningful error message

# Before
return f"❌ Message send error: {str(e)[:200]}"

# After
err_detail = str(e) or type(e).__name__
return f"❌ Message send error: {err_detail[:200]}"

ReadTimeout (and any other exception with an empty str()) now surfaces its type name instead of a blank string.

Result

Scenario	Before	After
Single transient timeout	Task aborted	Silent retry, task continues
3 consecutive timeouts	"Message send error:"	"Message send error: ReadTimeout"
Other exceptions	May show blank cause	Always shows type.__name__ as fallback

Files changed

• backend/app/services/agent_tools.py — _send_message_to_agent only

🤖 Generated with Claude Code

[Congregalis]

Thanks for picking this up. I took a look and it seems this PR overlaps quite a bit with #146, since both are addressing the same issue in #143 around send_message_to_agent timeout retries and error reporting.

I already opened #146 earlier for the same underlying problem, and it currently covers a slightly broader set of retry/error-handling cases as well. To avoid duplicate review effort, it may make sense to consolidate the discussion into one PR.

If maintainers prefer the smaller scoped approach here, I’m happy to align and adjust #146 accordingly.