What happened?

Description

version: v0.3.0.Final, v0.3.1.Final

When calling DefaultRequestHandler.onMessageSend with blocking=true, it is expected that the handler waits for the final state result before returning the response.
However, according to the test case below, the first message is returned immediately, and the remaining messages are processed in the background:

🔗 DefaultRequestHandlerTest.java#L504

This behavior seems indistinguishable from the blocking=false case.

Background

I understand that ResultAggregator was modified to run subscription logic on a background thread to prevent blocking the Vert.x worker thread, as indicated by the following comment:

// CRITICAL: The subscription itself must run on a background thread to avoid blocking
// the Vert.x worker thread. EventConsumer.consumeAll() starts a polling loop that
// blocks in dequeueEventItem(), so we must subscribe from a background thread.
// Use the @internal executor (not ForkJoinPool.commonPool) to avoid saturation

🔗 ResultAggregator.java#L121-L125

However, for requests where blocking=true, it is still expected that the DefaultRequestHandler waits for background task completion and returns the final aggregated result.

Currently, even though cleanupProducer calls bothComplete.join(), the handler does not appear to wait as intended.

🔗 DefaultRequestHandler.java#L607

Expected Behavior

When blocking=true, DefaultRequestHandler should:

Wait for all background tasks to complete (including final state aggregation).

Return the final response only after all events have been processed.

Actual Behavior

The first message is returned immediately.

Remaining events are processed asynchronously in the background.

Behavior is effectively identical to blocking=false.

Request

Please review the intended behavior for blocking=true requests and confirm whether the current implementation aligns with the design goals.
If not, it may require ensuring that bothComplete.join() properly waits for all background processing before returning the response.

Relevant log output

Code of Conduct

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