Skip to content

v0.8.2 — A2A gateway fixes

Choose a tag to compare

View all tags
@github-actions github-actions released this 11 Aug 05:11
· 221 commits to main since this release
v0.8.2
bd88f8b

🚀 Get started

New to AISIX? Get the gateway running and route your first LLM request in minutes:

📦 Download

Pull the container image from the GitHub Container Registry:

docker pull ghcr.io/api7/aisix:0.8.2

Rolling tags (0.8, latest) and the docker.io/api7/aisix mirror for private/offline deployments are listed on the package page.

A maintenance release for the A2A gateway. The endpoint shipped with the pieces
around it in place — caller authentication, per-agent access control, traffic
controls, telemetry — but three faults on the upstream-facing side meant a
registered agent could not always be reached, and the two methods used to watch
a long-running task could not be used at all. All three are fixed here.

🧩 A2A gateway

  • The gateway announces the agent's pinned wire version in the A2A-Version header on every call it makes to that agent, including the agent-card fetch (#914). Nothing sent the header before, and the A2A specification tells an agent to read its absence as version 0.3 — so an agent pinned to 1.0 answered VersionNotSupportedError, and the registered protocol_version had no effect. A version supplied by the caller does not override the registered pin.
  • An agent whose card is published under a path prefix now resolves (#914). The well-known card URI was built at the origin, discarding the path the agent was registered with, so an agent behind an ingress path — or on a platform that gives each tenant a prefix — was asked for a card it does not serve there, and the platform's catch-all 405 came back as the agent's own answer.
  • The card the gateway serves points every advertised address back at the gateway: the top-level url and each entry under supportedInterfaces and additionalInterfaces (#914). Only the top level was rewritten before, and a 1.0 caller reads its endpoint out of supportedInterfaces — so it could reach the upstream agent directly, bypassing caller authentication and per-agent access control.
  • message/stream and tasks/resubscribe relay the agent's event stream as it arrives (#916). Both were served through the single-response path, which buffered the whole body and parsed it as one JSON document; an event stream is not valid JSON, so both methods failed with 502. Events are reassembled across chunk boundaries, and a malformed event ends the stream with an error rather than being skipped, so a truncated task cannot read as a completed one.

🔌 Configuration

  • The A2A agent and MCP server rules — the name shape, the credential each auth_type requires, and the fields an OpenAPI-backed MCP server needs — are enforced on every configuration path, not only this gateway's Admin API (#848). A definition that breaks one of them is reported with the entry and the missing property named.

⚠️ Behavior change

A resources file carrying an A2A agent or MCP server definition that breaks one
of those rules no longer loads, so a gateway configured that way stops at
startup with the offending entry named instead of running with a definition
that cannot work — an agent named with a / splits its own /a2a/<name> route
in two, and auth_type: bearer with no secret authenticates upstream with
nothing.

What to check before upgrading, per entry:

Entry Requirement
a2a_agents[].name, mcp_servers[].name a single URL-safe path segment; no __ in an MCP server name
auth_type: bearer / api_key secret present and non-empty
auth_type: oauth2 (MCP) secret, client_id and token_url present
type: openapi (MCP) spec present

Validate a file before rolling it out:

aisix validate --resources /etc/aisix/resources.yaml

A gateway managed by AISIX Cloud is unaffected: those rules already applied when
the resource was created, and such a gateway rejects only the offending entry
and keeps serving the rest.

Full Changelog: v0.8.1...v0.8.2

Assets 2
Loading