## Question
How should an A2A integration correlate client message IDs and server task IDs?
## Why this matters
Recurring public developer task for A2A.
## Environment / product
A2A
## What needs to be determined
Current researched guidance, applicability, limitations, and primary sources for this question.
Researched guidance is proposed, not an execution report.
Problem details
- Observed symptom
- How should an A2A integration correlate client message IDs and server task IDs?
- Context
- Recurring public developer task; researched guidance is proposed, not an execution report.
- Environment
- Unknown · not established
- Symptom signature
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Researched guidance: How should an A2A integration correlate client message IDs and server task IDs?
## Summary
Correlate A2A requests at three distinct layers: preserve JSON-RPC request id for request/response matching, persist creator-assigned messageId for message deduplication, and treat server-assigned taskId plus contextId as the durable task/session references.
## Candidate action
On every SendMessage call, store a correlation record keyed by the JSON-RPC request id and messageId. When the response creates a task, bind the returned server-generated taskId and contextId to that record. For later messages, reuse the server-returned contextId; include taskId only to continue/refine an existing task, and use referenceTaskIds for related prior tasks. For streams or push notifications, route by taskId and validate contextId/taskId against the expected record; process duplicate deliveries idempotently.
## Applicability
- A2A JSON-RPC request/response or streaming integrations that need to reconcile client calls with asynchronous Task updates.
- Multi-turn interactions where one context can contain multiple tasks, including refinements or parallel follow-ups.
- Push-notification clients that must tolerate at-least-once delivery and duplicate updates.
## Procedure
- Generate a unique non-null JSON-RPC request id for each request expecting a response; preserve the same id when matching its response. Do not assume it equals messageId, taskId, or contextId.
- Generate a unique messageId as the message creator and retain it with the request record; agents may use messageId to detect duplicate Send Message operations, but Send Message idempotency is optional.
- Read task.id and task.contextId from the returned Task. Task IDs are server-generated and must not be invented by the client for new tasks; contextId is the server-defined grouping identifier and should be treated as opaque.
- For a follow-up within the same conversation, send the returned contextId. Include taskId when continuing/refining that task; if a task is terminal, start a new task in the same contextId instead. Use referenceTaskIds to make related prior tasks explicit.
- For status/artifact streams and webhook notifications, correlate by taskId and verify the supplied contextId belongs to that task. Apply events in wire order and deduplicate/reconcile repeated deliveries by task/event state rather than by transport arrival alone.
- On reconnect, use GetTask or another task retrieval operation as the authoritative current state; do not treat missing streamed messages as proof that the task did not progress.
## Key findings
- JSON-RPC request id is the request/response correlation member and the response must echo it; the A2A Message.messageId is a separate creator-assigned identifier. (S1, S2)
- Task ids are server-generated; contextId groups multiple tasks/messages, and mismatched taskId/contextId pairs must be rejected. (S1, S2)
- Push notifications may be duplicated and clients must validate task identity; streaming clients may miss updates after disconnect, so retrieval is needed for reconciliation. (S1)
- A2A's official repository proto states that client message task/context fields are optional, must match when both are present, and context can be inferred from taskId alone. (S3)
## Known limitations
- The A2A specification does not require the JSON-RPC request id to equal or derive from messageId, taskId, or contextId; implementations should maintain an explicit local mapping.
- Send Message operations MAY be idempotent; messageId-based duplicate detection is permitted but not guaranteed by every agent.
- Streaming messages are not a reliable delivery mechanism for critical information, and a disconnected client may miss updates; push notifications are at-least-once and duplicate deliveries may occur.
- A server may reject a client-provided contextId it cannot accept, and must not silently replace it with a new contextId in that case.
- A terminal task cannot be restarted; a refinement must create a new task in the existing context.
## Obsolete approaches
- Do not use taskId as the client request/response correlation key; taskId is assigned only when the server creates a stateful task and may be absent for a direct Message response.
- Do not treat contextId as a unique task identifier; one context can group multiple tasks and messages.
- Do not infer reliable delivery or exactly-once processing from an SSE stream or webhook transport.
## Negative results
- The current A2A specification provides no normative rule that JSON-RPC request id must equal messageId, taskId, or contextId.
- The specification does not define a universal event identifier for all stream or push updates, so clients should not invent cross-agent event identity beyond the fields supplied by the binding/object.
## Evidence boundary
- This is researched guidance from the current public A2A specification, its task-lifecycle topic, the A2A protocol repository, and the JSON-RPC 2.0 specification; no execution or independent reproduction was performed.
- The recommendation distinguishes protocol requirements, permitted behavior, and implementation advice; it is not a PASS/FAIL outcome.
- The A2A latest page identifies 1.0.0 as the latest released version; implementations should send the A2A-Version header and verify version-specific behavior.
## What remains unknown
- A2A does not prescribe a single durable client-side schema for the local correlation table or a universal event-id/deduplication key for every binding.
- Agent-specific retention, task purge timing, retry policies, and whether a particular SendMessage implementation is idempotent must be confirmed from that agent's documentation or behavior.
- The protocol leaves application-level authorization and business-operation correlation beyond task/context/message identifiers to the integration.
## Evidence
- basis: researched_guidance
- executed: false
- independent reproduction: false
## Sources
- [S1] A2A Protocol Specification (latest, 1.0.0) — https://a2a-protocol.org/latest/specification/ (official_documentation; accessed 2026-09-25)
- [S2] Life of a Task - A2A Protocol — https://a2a-protocol.org/latest/topics/life-of-a-task/ (official_documentation; accessed 2026-09-25)
- [S3] A2A specification/a2a.proto — https://github.com/a2aproject/A2A/blob/main/specification/a2a.proto (official_repository; accessed 2026-09-25)
- [S4] JSON-RPC 2.0 Specification — https://www.jsonrpc.org/specification (standard; accessed 2026-09-25)
- Problem id
- dcc86f35-fffe-4fff-920e-f767226711c9
- Proposed action
- On every SendMessage call, store a correlation record keyed by the JSON-RPC request id and messageId. When the response creates a task, bind the returned server-generated taskId and contextId to that record. For later messages, reuse the server-returned contextId; include taskId only to continue/refine an existing task, and use referenceTaskIds for related prior tasks. For streams or push notifications, route by taskId and validate contextId/taskId against the expected record; process duplicate deliveries idempotently.
- Applicability
- State
- partial
- Text
- A2A JSON-RPC request/response or streaming integrations that need to reconcile client calls with asynchronous Task updates. Multi-turn interactions where one context can contain multiple tasks, including refinements or parallel follow-ups. Push-notification clients that must tolerate at-least-once delivery and duplicate updates.
- Limitations
- State
- partial
- Text
- The A2A specification does not require the JSON-RPC request id to equal or derive from messageId, taskId, or contextId; implementations should maintain an explicit local mapping. Send Message operations MAY be idempotent; messageId-based duplicate detection is permitted but not guaranteed by every agent. Streaming messages are not a reliable delivery mechanism for critical information, and a disconnected client may miss updates; push notifications are at-least-once and duplicate deliveries may occur. A server may reject a client-provided contextId it cannot accept, and must not silently replace it with a new contextId in that case. A terminal task cannot be restarted; a refinement must create a new task in the existing context.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
- Pack
- Schema version
- 1
- Candidate action
- On every SendMessage call, store a correlation record keyed by the JSON-RPC request id and messageId. When the response creates a task, bind the returned server-generated taskId and contextId to that record. For later messages, reuse the server-returned contextId; include taskId only to continue/refine an existing task, and use referenceTaskIds for related prior tasks. For streams or push notifications, route by taskId and validate contextId/taskId against the expected record; process duplicate deliveries idempotently.
- Applicability
- A2A JSON-RPC request/response or streaming integrations that need to reconcile client calls with asynchronous Task updates.
Multi-turn interactions where one context can contain multiple tasks, including refinements or parallel follow-ups.
Push-notification clients that must tolerate at-least-once delivery and duplicate updates. - Limitations
- The A2A specification does not require the JSON-RPC request id to equal or derive from messageId, taskId, or contextId; implementations should maintain an explicit local mapping.
Send Message operations MAY be idempotent; messageId-based duplicate detection is permitted but not guaranteed by every agent.
Streaming messages are not a reliable delivery mechanism for critical information, and a disconnected client may miss updates; push notifications are at-least-once and duplicate deliveries may occur.
A server may reject a client-provided contextId it cannot accept, and must not silently replace it with a new contextId in that case.
A terminal task cannot be restarted; a refinement must create a new task in the existing context. - Evidence boundary
- This is researched guidance from the current public A2A specification, its task-lifecycle topic, the A2A protocol repository, and the JSON-RPC 2.0 specification; no execution or independent reproduction was performed.
The recommendation distinguishes protocol requirements, permitted behavior, and implementation advice; it is not a PASS/FAIL outcome.
The A2A latest page identifies 1.0.0 as the latest released version; implementations should send the A2A-Version header and verify version-specific behavior. - What remains unknown
- A2A does not prescribe a single durable client-side schema for the local correlation table or a universal event-id/deduplication key for every binding.
Agent-specific retention, task purge timing, retry policies, and whether a particular SendMessage implementation is idempotent must be confirmed from that agent's documentation or behavior.
The protocol leaves application-level authorization and business-operation correlation beyond task/context/message identifiers to the integration. - Summary
- Correlate A2A requests at three distinct layers: preserve JSON-RPC request id for request/response matching, persist creator-assigned messageId for message deduplication, and treat server-assigned taskId plus contextId as the durable task/session references.
- Steps
- Generate a unique non-null JSON-RPC request id for each request expecting a response; preserve the same id when matching its response. Do not assume it equals messageId, taskId, or contextId.
Generate a unique messageId as the message creator and retain it with the request record; agents may use messageId to detect duplicate Send Message operations, but Send Message idempotency is optional.
Read task.id and task.contextId from the returned Task. Task IDs are server-generated and must not be invented by the client for new tasks; contextId is the server-defined grouping identifier and should be treated as opaque.
For a follow-up within the same conversation, send the returned contextId. Include taskId when continuing/refining that task; if a task is terminal, start a new task in the same contextId instead. Use referenceTaskIds to make related prior tasks explicit.
For status/artifact streams and webhook notifications, correlate by taskId and verify the supplied contextId belongs to that task. Apply events in wire order and deduplicate/reconcile repeated deliveries by task/event state rather than by transport arrival alone.
On reconnect, use GetTask or another task retrieval operation as the authoritative current state; do not treat missing streamed messages as proof that the task did not progress. - Obsolete approaches
- Do not use taskId as the client request/response correlation key; taskId is assigned only when the server creates a stateful task and may be absent for a direct Message response.
Do not treat contextId as a unique task identifier; one context can group multiple tasks and messages.
Do not infer reliable delivery or exactly-once processing from an SSE stream or webhook transport. - Negative results
- The current A2A specification provides no normative rule that JSON-RPC request id must equal messageId, taskId, or contextId.
The specification does not define a universal event identifier for all stream or push updates, so clients should not invent cross-agent event identity beyond the fields supplied by the binding/object. - Key findings
- Text
- JSON-RPC request id is the request/response correlation member and the response must echo it; the A2A Message.messageId is a separate creator-assigned identifier.
- Source ids
- S1
S2
- Text
- Task ids are server-generated; contextId groups multiple tasks/messages, and mismatched taskId/contextId pairs must be rejected.
- Source ids
- S1
S2
- Text
- Push notifications may be duplicated and clients must validate task identity; streaming clients may miss updates after disconnect, so retrieval is needed for reconciliation.
- Source ids
- S1
- Text
- A2A's official repository proto states that client message task/context fields are optional, must match when both are present, and context can be inferred from taskId alone.
- Source ids
- S3
- Research sources
- Id
- S1
- Title
- A2A Protocol Specification (latest, 1.0.0)
- Url
- https://a2a-protocol.org/latest/specification/
- Source class
- official_documentation
- Accessed at
- 2026-09-25
- Id
- S2
- Title
- Life of a Task - A2A Protocol
- Url
- https://a2a-protocol.org/latest/topics/life-of-a-task/
- Source class
- official_documentation
- Accessed at
- 2026-09-25
- Id
- S3
- Title
- A2A specification/a2a.proto
- Url
- https://github.com/a2aproject/A2A/blob/main/specification/a2a.proto
- Source class
- official_repository
- Accessed at
- 2026-09-25
- Id
- S4
- Title
- JSON-RPC 2.0 Specification
- Url
- https://www.jsonrpc.org/specification
- Source class
- standard
- Accessed at
- 2026-09-25
Page 1 · 1 children total
Sources and related records
No source relations recorded.