Query result is null when query is "forwarded"

[igorgiovannini]

Maybe the behaviour I'm encountering is expected by design like so, but it may be worth asking...

I have a Query Handler (obviously registered) named ReceivedDocumentQueriesHandler.
This handler, handles a query named GetReceivedDocumentBinaryByPublicIdQuery (which extends IQuery<BinaryModel>). The idea is to have a handler that acts as a sort of router (like i.e. an IntegrationEventsMapper)

In my domain the "entity" ReceivedDocument is of two distinct types (neither extends a particular abstract class) and are completely different, therefore I have other two specific Queries Handlers:

• XxxLegacyReceivedDocumentQueriesHandler
• XxxReceivedDocumentQueriesHandler

There are two specific queries handled in their own Queries Handler:

• GetXxxReceivedDocumentBinaryByPublicIdQuery
• GetXxxLegacyReceivedDocumentBinaryByPublicIdQuery

Both the queries extend IQuery<BinaryModel> and therefore return a BinaryModel.

The ReceivedDocumentQueriesHandler, for a GetReceivedDocumentBinaryByPublicIdQuery, returns a query depending on the type specified as an attribute in the query (Legacy or not, the type is taken from a query param in the controller and then sent forward in the query).
The returned query is then consumed in the pipeline and the result is returned, but the result is not returned where the QueryPublisher has been invoked.

Call stack:
Controller
|- Invokes ExecuteAsync of the QueryPublisher
|-- ReceivedDocumentQueriesHandler reacts and returns the expected query
|--- The specific query handler reacts to the previous query and returns the result
|- ExecuteAsync result is null

Otherwise, I have to switch the type directly in the controller and publish the right query instead of having it handled in the QueryHandler (a QueryHandler for the two types and so having two injected repositories is not something I'd like to take into consideration).

[BEagle1984]

We talked about this already IRL but let's drop a note in here as well.

This is a usage I didn't actually foresee. I hadn't think about using the implicit automatic republishing of the returned messages as a way to build a sort of dispatcher/router for queries and commands.
Since I didn't imagine this case, it's of course not implemented but I don't see a reason why it couldn't actually be done.

I need to invest some time to analyze this a bit deeper and I'll report back.