Support for long-running background after original `EventQueue`

[martimfasantos]

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

Description:
When using the EventQueue in the current A2A examples, the queue is closed automatically after the request completes. This causes issues for long-running background tasks (like reminders or notifications) that attempt to enqueue events after the request has finished.

Observed behavior:

• Background tasks finish successfully.

• Attempting to enqueue events via the original EventQueue results in warnings like:

  Queue is closed. Event will not be enqueued.
  

• Any updates or artifacts pushed after the request cannot be delivered through the closed queue.

Context / use case:
This is needed for features like reminders, scheduled notifications, or other tasks that run asynchronously and complete after the original agent request has finished.

---

Questions:

• Does A2A currently support this pattern?
• Can this behavior be reproduced using the protocol as it stands?
• Are there any recommended examples or best practices for implementing long-running background tasks that deliver updates back to the client?

Thank you!

Describe the solution you'd like

• Support a mechanism for long-running tasks to send updates or final artifacts back to the client even after the request has completed.

[thkodin]

This particular line in the event consumer's final event handling block is probably causing this. The close is called with immediate=True, which for the EventQueue, will also immediately close any child queues as well, and unprocessed events would be lost.

I require similar functionality for logging events by tapping the event queue and setting up logging tasks using the tapped queue inside a wrapper that decorates the execute and cancel methods. However, in my case, the last few events that updated artifacts and immediately used updater.complete (or any terminal state for that matter) tend to never be processed because the background task consuming from the tapped queue had not processed the tapped queue yet, and the artifact updates were lost as part of the immediate shutdown. If I put in a sleep before triggering the final update, they go through.

I have currently setup a custom subclass of the EventConsumer and the DefaultRequestHandler (that seems to be setting up the consumers) and made this configurable. The graceful queue shutdown, if enabled, is run inside a wait_for() with a configurable timeout that, if exceeded, cancels the graceful shutdown and starts the immediate shutdown as before. Not sure how effective this would be especially in edge cases where the parent queue is shutdown but not the child queues, etc. I'll see if I can setup tests for those cases.

I would be able to test this with a basic agent tomorrow for Python 3.13 and then share the implementation if it works. I am not sure if it is exactly relevant to your use case, but I do believe it is caused by the same problem / design choice, so it might help.

[thkodin]

So it worked! But testing the edge cases would be very important. I'll set those up tomorrow and report back.

In the meanwhile, this gist contains the sub-classes I created to get the logging working with graceful queue shutdown as a configurable parameter.

Then, in the agent's __main__.py, simply use SafeRequestHandler instead of DefaultRequestHandler:

# ...import SafeRequestHandler here...

def main():
    # ...rest of the code...

    request_handler = SafeRequestHandler(
        agent_executor=agent_executor,
        # ...any additional arguments...
    )

if __name__ == "__main__":
    main()