[Feat]: Can the A2A server generate taskids by itself?

[likai314]

Is your feature request related to a problem? Please describe.

In the current SDK, after receiving a message, if it does not contain a taskid, the SDK will generate one automatically. This brings two problems:

1. If the agent expects to attach the received message to an existing task, the new taskid will conflict with the original one;
2. In practical use, organizations expect taskids to have a unified prefix or a unified organizational form, and do not want to use taskids automatically generated by the SDK.
   Please consider the above situations and add a configuration method to prevent the SDK from automatically generating taskids after receiving messages?

Describe the solution you'd like

add a configuration method to prevent the SDK from automatically generating taskids after receiving messages without taskid.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[RubberGoose246]

This highlights a fundamental issue with how A2A handles task ID assignment. Since the framework generates a task ID internally, applications are unable to freely assign their own task ID — a problem I’ve also encountered.

Whether an agent tries to pass a task ID (not generated by the agent itself) to the client, or the client tries to pass such a task ID to the agent, it results in an error because the framework expects the task ID to match its internal management.

What complicates things further is that the task history stored in the DatabaseTaskStore or DatabasePushNotificationConfigStore is only associated with task IDs generated by the framework. This means that the history functionality cannot be used with application-defined task IDs. The same limitation applies to task state management, particularly in handling terminal states.

I think the confusion stems from the fact that the framework-managed task ID is also exposed for application use. While it's reasonable for the framework to manage its own internal tasks, I believe it would be better to completely separate that from application-level task management.

[likai314]

hi @kthota-g
Could you kindly consider integrating my issue above into A2A sdk?
Thank you very much.

[likai314]

hi @holtskinner
Could you kindly consider integrating my issue above into A2A sdk?
Thank you very much.

[pstephengoogle]

Thanks for this feedback. For issue 1) the expectation is that the second request is attached to the task explicitly in the request. If you don't provide a task that message is associated with, the agent must assume this is a new request and can decide how to proceed.

Will look into 2)

[pstephengoogle]

Follow up question for 2). If you could supply your own id generator to the sdk, would that resolve all your concerns? Having the caller provide the task id creates its own set of challenges, but if the agent developer could adhere to expected standards, that should work, right?