[Command|Query]ChannelImpl loops over empty map during `doCreate...Stream` and logs success - although no handlers are present

[jangalinski]

Basic information

This was observed while fixing axonframework-app startup-behavior when server is not available (see AxonFramework/AxonFramework#3938).

The problem applies to both QueryChannelImpl and CommandChannelImpl, for examples, we focus on commands.

The base problem is, that doCreateCommandStream loops over a map of queries or commandHandlers that is empty. Optional.orElse then gives a successfull CompletableFuture so the logger always reports success, although later registered handlers might fail (due to unavailability).

This is not a bug of the registration per se, if the server is available, handlers can be used correctly, but it is misleading when starting the app without server connection.

Steps to reproduce

Start an app using axon framework 5 with axonserver enabled and server not running.
Check the logs, and/or debug.

Expected behaviour

when doCreateCommandStream loops over all commandHandlers, the handlers are already put to the map, so sendSubscribeis called for each handler, and success failure is logged correctly.

Actual behaviour

When doCreateCommandStream is called via connect or registerCommandHandler, the Map commandHandlers is still empty. As a fallback, an empty future is used, which leads to

.orElse(CompletableFuture.completedFuture(null))
                       .whenComplete((unused, throwable) -> {
                           if (throwable != null) {
                               logger.warn("An error occurred while registering command handlers", throwable);
                           } else {
                               logger.info("CommandChannel for context '{}' connected, {} command handlers registered", context, commandHandlers.size());
                           }
                           subscriptionsCompleted.set(throwable == null);
                       });

always reporting "0 command handlers registered".

[jangalinski]

Turns out even when server is available, the log output always is

CommandChannel for context 'default' connected, 0 command handlers registered