fix: Remove awaitQueuePollerStart to eliminate thread blocking bottleneck

Problem:
- TCK tests timing out in CI with 11 leaked agents (183 registered, 172 removed)
- Agent-executor threads blocking up to 10 seconds waiting for queue polling to start
- Cascading delays when Vert.x worker threads are busy (11 × 10s = 110s+ wasted time)
- Tests timeout at 5 minutes before cleanup can execute

Root Cause:
Agent-executor threads (limited pool of 15) were blocking in awaitQueuePollerStart()
waiting for Vert.x worker threads to become available and start polling queues.
This created a resource bottleneck where valuable executor threads sat idle.

Solution:
Remove synchronous wait and move queue lifecycle entirely to the consumer:
- Agent-executor thread: Returns immediately after execution, no blocking
- Consumer (Vert.x worker): Handles all queue lifecycle via EventConsumer.consumeAll()
- Background cleanup: Manages ChildQueue/MainQueue reference counting

Changes:
- DefaultRequestHandler.registerAndExecuteAgentAsync():
  * Removed awaitQueuePollerStart() call
  * Removed immediate queue closing in whenComplete()
  * Added architecture documentation
- Queue lifecycle now managed entirely by EventConsumer.consumeAll()
  which closes queue on final events/errors

Benefits:
- Eliminates cascading 10-second delays
- Better thread utilization (no idle blocking)
- Simpler architecture (consumer owns lifecycle)
- No race conditions (consumer running before it can close queue)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: kabir

server-common/src/main/java/io/a2a/server/requesthandlers/DefaultRequestHandler.java

@@ -483,6 +483,17 @@ private boolean shouldAddPushInfo(MessageSendParams params) {
         return pushConfigStore != null && params.configuration() != null && params.configuration().pushNotificationConfig() != null;
     }
 
+    /**
+     * Register and execute the agent asynchronously in the agent-executor thread pool.
+     *
+     * Queue Lifecycle Architecture:
+     * - Agent-executor thread: Executes agent and enqueues events, returns immediately
+     * - Vert.x worker thread (consumer): Polls queue, processes events, closes queue on final event
+     * - Background cleanup: Manages ChildQueue/MainQueue lifecycle after agent completes
+     *
+     * This design avoids blocking agent-executor threads waiting for consumer polling to start,
+     * eliminating cascading delays when Vert.x worker threads are busy.
+     */
     private EnhancedRunnable registerAndExecuteAgentAsync(String taskId, RequestContext requestContext, EventQueue queue) {
         LOGGER.debug("Registering agent execution for task {}, runningAgents.size() before: {}", taskId, runningAgents.size());
         logThreadStats("AGENT START");
@@ -492,11 +503,9 @@ public void run() {
                 LOGGER.debug("Agent execution starting for task {}", taskId);
                 agentExecutor.execute(requestContext, queue);
                 LOGGER.debug("Agent execution completed for task {}", taskId);
-                try {
-                    queueManager.awaitQueuePollerStart(queue);
-                } catch (InterruptedException e) {
-                    Thread.currentThread().interrupt();
-                }
+                // No longer wait for queue poller to start - the consumer (which is guaranteed
+                // to be running on the Vert.x worker thread) will handle queue lifecycle.
+                // This avoids blocking agent-executor threads waiting for worker threads.
             }
         };
 
@@ -505,18 +514,11 @@ public void run() {
                     if (err != null) {
                         LOGGER.error("Agent execution failed for task {}", taskId, err);
                         runnable.setError(err);
-                        // Close queue on error
-                        queue.close();
-                    } else {
-                        // Only close queue if task is in a final state
-                        Task task = taskStore.get(taskId);
-                        if (task != null && task.getStatus().state().isFinal()) {
-                            LOGGER.debug("Task {} in final state {}, closing queue", taskId, task.getStatus().state());
-                            queue.close();
-                        } else {
-                            LOGGER.debug("Task {} not in final state or not yet created, keeping queue open", taskId);
-                        }
+                        // Don't close queue here - let the consumer handle it via error callback
+                        // This ensures the consumer (which may not have started polling yet) gets the error
                     }
+                    // Queue lifecycle is now managed entirely by EventConsumer.consumeAll()
+                    // which closes the queue on final events. No need to close here.
                     logThreadStats("AGENT COMPLETE END");
                     runnable.invokeDoneCallbacks();
                 });

tck/src/main/resources/application.properties

@@ -8,8 +8,12 @@ a2a.executor.core-pool-size=5
 a2a.executor.max-pool-size=15
 a2a.executor.keep-alive-seconds=60
 
-# Increase Vert.x worker thread blocking timeout to prevent thread abandonment
-# Default is 60s, increase to 300s (5 minutes) to match TCK timeout
+# TEMPORARY WORKAROUND: Increase Vert.x worker thread blocking timeout to prevent thread abandonment
+# Default is 60s, increased to 300s (5 minutes) to match TCK timeout
+# TODO: Remove this workaround once proper fix is implemented:
+#       - Make EventQueue polling non-blocking with async/reactive patterns
+#       - Or add timeout to consumeAndBreakOnInterrupt() to return early
+# See: Investigation of TCK timeout issues in CI (21 agents leaked due to thread abandonment)
 quarkus.vertx.max-worker-execute-time=300s
 
 # Enable debug logging for troubleshooting SSE streaming test timeouts