Skip to content

fix(a2a-adapter): add follow_redirects=True to httpx AsyncClient calls - #868

Open
bleib1dj wants to merge 7 commits into
fetchai:mainfrom
bleib1dj:v2_upgrade
Open

fix(a2a-adapter): add follow_redirects=True to httpx AsyncClient calls#868
bleib1dj wants to merge 7 commits into
fetchai:mainfrom
bleib1dj:v2_upgrade

Conversation

@bleib1dj

Copy link
Copy Markdown
Contributor

Summary

httpx.AsyncClient defaults follow_redirects to False, causing 308 Permanent Redirect responses from Agentverse and A2A endpoints to be returned as errors instead of being followed. This affects agent discovery, health checks, message sending, and LLM routing in the A2A outbound adapter.

This is a companion fix to flockx-official/platform#11263, which addresses the same issue in the platform codebase.

Notable changes

  • a2a_outbound/adapter.py - 4 httpx.AsyncClient instantiations now include follow_redirects=True:
    • _send_to_a2a_agent (message sending)
    • _discover_and_health_check_agents (agent card fetching)
    • route_to_llm (LLM API routing)
    • Agent card well-known endpoint fetching

How tested

  • Code review of all httpx.AsyncClient instantiations in the adapter
  • Confirmed the change is additive - no behavioral change for endpoints that do not redirect

Risks / breaking changes

None. Adding follow_redirects=True makes httpx behave like requests and aiohttp do by default.

bleib1dj added 7 commits June 23, 2025 16:58
httpx.AsyncClient defaults follow_redirects to False, causing 308
Permanent Redirect responses from Agentverse and A2A endpoints to be
returned as errors instead of followed. Affects agent discovery, health
checks, message sending, and LLM routing.
Comment on lines +543 to 553
logger.info("successfully registered to Agentverse.")

# set agent as active
if agent_registration.active:
try:
logger.info("setting agent as active...")
_update_agent_status(True, identity)
logger.info("successfully set agent to active.")
except AgentverseRequestError as e:
logger.warning(f"failed to set agent as active. {str(e)}")
logger.info("setting agent as active...")
_update_agent_status(True, identity)
logger.info("successfully set agent to active.")

return True


def register_chat_agent(

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The error handling in register_agent() and register_chat_agent() was changed, causing AgentverseRequestError to propagate instead of being silently handled. This is an undocumented breaking change.
Severity: HIGH

Suggested Fix

The breaking change should be explicitly documented in the pull request description and release notes to inform users of the new behavior. Alternatively, revert the change to maintain backward compatibility or introduce a new function for the new behavior. The change should not be bundled with an unrelated bug fix.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: python/uagents-core/uagents_core/utils/registration.py#L533-L553

Potential issue: The functions `register_agent()` and `register_chat_agent()` were
modified to no longer catch `AgentverseRequestError`. Previously, registration failures
were logged and the function returned `None`, allowing the calling application to
continue execution. With the new changes, if registration fails, the
`AgentverseRequestError` will propagate unhandled. This can crash any downstream
application that calls these functions without its own `try/except` block, as they may
not be prepared to handle this exception. This constitutes a breaking API change that
was not documented in the pull request description.

Did we get this right? 👍 / 👎 to inform future reviews.

@Warren-Bertram

Copy link
Copy Markdown

Real-world repro context: hosted mailbox A2A agent (PropertyAI Advisor)

Sharing an external A2A agent setup that hits this exact class of failure. Happy to help validate once this lands.

Setup / workflow

  1. Built a Starlette A2A agent (a2a-sdk 1.x) with JSON-RPC at / and agent card at /.well-known/agent-card.json.
  2. Connected it in Agentverse via Launch an Agent → Connect Agent → A2A Protocol → Mailbox relay (not public endpoint).
  3. Deployed always-on on Railway with Agentverse bridge + mailbox enabled (USE_MAILBOX=1), polling the mailbox with the URI from onboarding (handle:secret@agentverse.ai/...).
  4. Public JSON-RPC on the Railway URL answers correctly when called directly (e.g. hello / SendMessage with A2A-Version: 1.0).
  5. Chat from Agentverse / ASI:One does not produce any incoming message on the Railway poller — no [incoming message] logs.

Agent listing: mailbox-relay A2A agent property-ai-advisor / Property AI Advisor.
Public endpoint (works when called directly): https://property-ai-agent-production.up.railway.app/

What fails

When chatting to the hosted A2A agent through Agentverse/ASI:One we see HTTP 308 Permanent Redirect failures on the client side.

Root cause matches this PR: httpx.AsyncClient defaults to follow_redirects=False, so 308s from Agentverse/A2A endpoints (often trailing-slash redirects from Starlette / slash-sensitive paths) are returned as errors instead of being followed.

That lines up with:

  • Starlette (and many servers) answering slash mismatches with 308
  • Agentverse/A2A clients using httpx with follow_redirects=False
  • Discovery / registration evaluation / chat failing before mailbox handoff completes → no inbound message on the Railway poller

Ask (same as this PR)

Please set follow_redirects=True on the httpx clients used for:

  • sending messages to A2A agents
  • agent-card / well-known discovery
  • health checks / registration evaluation

Same class of fix is needed anywhere Agentverse/ASI:One calls A2A over httpx (companion: flockx-official/platform#11263).

Why this matters beyond this agent

Most external A2A setups hit this: JSON-RPC served at / (or any slash-sensitive path) + trailing-slash agent-card URLs. Following redirects on the platform/client side is the proper fix; agent deploys can stay as-is meanwhile.

Extra constraint we hit

URI was fixed at mailbox onboarding; we cannot re-evaluate or switch to a public endpoint without a new profile. So until redirect-following lands, mailbox chat stays broken even though the public Railway JSON-RPC endpoint is healthy.

Thanks for the fix — landing this should unblock mailbox-relay A2A agents like this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants