If we have a EventRouter with a mapping e.g.

and we use for example the OnEventStrategy wants to call the onEvent() method, even if the class just uses __invoke() as callable.

So currently it is not possible to use more than one InvokeStrategy. If we use a specific InvokeStrategy we are bound to this InvokeStrategy

I propose to provide an interface for each InvokeStrategy (for the given methods e.g.)

interface UseHandleCommandStrategy {
    public interface handle(Message $message) : void;
}

interface UseOnEventStrategy {
    public interface onEvent(Message $message) : void;
}

interface UseFinderInvokeStrategy {
    public interface find(Message $message, $deferred) : void;
}

So we can build in a check if the handler wants to use a specific strategy:

foreach ($handlers as $handler) {
    if ($handler instanceof UseOnEventStrategy) {
        $handler->onEvent($message);
    }
}

Handler not implementing the interface will just be skipped, so multiple strategies are possible then.

Use case taken from the chat:

first round: http request -> command bus -> custom router checks if command should be handled async (marker interface) and has no "handled-by-queue" metadata set -> route to bernard -> bernard producer add command to queue second round: bernard consumer -> $command->withAddedMetadata('handled-by-queue', $queueName); -> command bus -> custom router sees the metadata key and now routes to command handler instead of bernard -> command handler -> ...

Idea: the AsyncSwitchMessageRouter can decorate a "standard router plugin" configured with the in-process message routes. The router should check either a specific message metadata key or if message implements an AsyncMessage marker interface (tbd) and route the message to a configured message producer. In the draft from the chat the consumer adds a metadata key to tell the router that the message was consumed from a queue. But the router should add such a metada key BEFORE it routes the message to a producer. So the router can check its own metadata key when it receives the message a second time. If the metadata key is present the AsyncSwitchMessageRouter delegates routing to its inner (decorated) router.

Prooph\ServiceBus\Plugin\ServiceLocatorPlugin relies onProoph\ServiceBus\MessageBus::EVENT_PARAM_MESSAGE_HANDLER, but the Prooph\ServiceBus\EventBus has its own EVENT_PARAM_EVENT_LISTENERS

This means that registering a ServiceLocatorPlugin against an EventBus is not causing any effect, as no events are intercepted.

This PR provides a bugfix for not resettable exceptions with finalize event.

• [x] add unit test which would fail without this PR
• [x] fix the bug

/cc @prolic please confirm this as a bug

I have tested 2 queries

`$this->queryBus->dispatch(new GetUserList( ))->then(
            function($result){
                dump($result); // some result
            }
        );

        $this->queryBus->dispatch( new GetUserList( ))->then(
            function($result)  {
                dump($result); // empty should be
            }
        )
        ;`

for first one handler i put sleep for 5 seconds, and here results are

//first - should be last, coz results + sleep
Paginator {#3327 ▼
...
}
//second, should be first, because no sleep + empty results
[]

Maybe i missed something, please tell me please.

Hi!

I am currently finding my way around with QueryBus. And I got confused with testing it. I created an empty project, pulled up just a few things:

"require": {
        "prooph/service-bus": "^6.0",
        "react/promise": "^2.5"
    },
    "require-dev": {
        "phpunit/phpunit": "^6.1"
    }

and then run this test:

<?php
declare(strict_types=1);


use PHPUnit\Framework\TestCase;
use Prooph\ServiceBus\QueryBus;

final class QueryTest extends TestCase
{
    function test_query() {
    
        $queryBus = new QueryBus();
        $queryBus->dispatch('anyname')->then(function(){
            //will not get there anyway
        }, function(Throwable $e){
            // Does nothing
            $this->fail($e->getMessage());
        });
        
    
    }
}

And it is green. I get control in second callable, but PHPUnit did not respect the fail() call at all.

Do you have any suggestions on how to test queries / how to fix that test?

P.s. I browsed through the proophessor-do but did not find query tests there.

This PR adds support for interop-config 1.0 and adds a new feature called static factories. Also dependencies are updated to latest versions and Composer scripts were added.

If this is ok, I will update the other packages in the same manner. /cc @codeliner

Note: We have some BC breaks of the factory methods because the interface of interop-config has changed. I think we should also mark the factories as final, because the config id (container id) is now configurable. What do you think?

Could we exchange \React\Promise\PromiseInterface for \React\Promise\ExtendedPromiseInterface which simply extends PromiseInterface but has the done method? see https://reactphp.org/promise/#extendedpromiseinterface

until #147 anyway

@prolic can you take over the release when everything is merged to develop?

Won't have much time the next days and then I'm off for 3 weeks.

/cc @guyradford

This change fixes an issue with OnEventStrategy not correctly determining the event name if a custom event returns a message name other than its own class name through the messageName() method.

public function __invoke(Message $message, Deferred $deferred = null):?Promise
{
    $needReply = (bool) $deferred;
    // stripped code. 
    if ($needReply) { 
        return new LazyPromise(function() use ($deferred, $reply) {
            $value = JSON::decode($reply->receive($this->replyTimeout)->getBody());

            try {
                $deferred->resolve($value);
            } catch (TimeoutException $e) {
                $deferred->reject($e->getMessage());
            }
        });
    }

But this is a BC an can only be done with a new major release.

Provide better explanation and examples of async message routing.

See chat discussion for the why?

Guy Radford @guyradford 22:08 ... I have managed to get the router to put the ActionEvent out through Bernard... but the router then try to route the message internally... I have trued to get$actionEvent->stopPropagation(true); and $actionEvent->setParam(MessageBus::EVENT_PARAM_MESSAGE_HANDLED, true); but neither works.

Alexander Miertsch @codeliner 22:27 ... Your router invokes BernardMessageProducer directly? If so, this is the problem. The router should route your command to the BernardMessageProducer only. All message producers are callable so they can be used as (or better replace) command handlers. We should make that more clear in the docs. For now take a look at the proophessor-do snapshot tutorial. In the last paragraph you can see how the TakeSnapshot command is routed to zeromq-message-producer instead of a in-process-command-handler (see the route config example). You just need to do the same in your application. You don't even need a specific router for the task.