Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Messenger][4.3] Tracker for changes #11236

Closed
weaverryan opened this issue Mar 28, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@weaverryan
Copy link
Member

commented Mar 28, 2019

A lot of new things have happened in Messenger for 4.3. This is a meta issue to try to track then:

@weaverryan weaverryan added this to the 4.3 milestone Mar 28, 2019

symfony-splitter pushed a commit to symfony/messenger that referenced this issue Mar 30, 2019

feature #30759 [Messenger] Adding the "sync" transport to call handle…
…rs synchronously (weaverryan)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Messenger] Adding the "sync" transport to call handlers synchronously

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | none
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

This adds a `sync://` transport that just calls the handlers immediately. Why? This allows you to route your messages to some "async" transport. But then, when developing locally or running your tests, you can choose to run them synchronously instead:

```yml
# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            async: '%env(MESSENGER_TRANSPORT_DSN)%'
        routing:
            'App\Message\SmsNotification': async
            'App\Message\OtherMessage': async
```

```
# .env
# by default, handle this sync
MESSENGER_TRANSPORT_DSN=sync://
```

```
# .env.local on production (or set this via real env vars)
# on production, use amqp
MESSENGER_TRANSPORT_DSN=amqp://.......
```

Cheers!

Commits
-------

3da5a438aa Adding the "sync" transport to call handlers synchronously

fabpot added a commit to symfony/symfony that referenced this issue Mar 30, 2019

feature #30759 [Messenger] Adding the "sync" transport to call handle…
…rs synchronously (weaverryan)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Messenger] Adding the "sync" transport to call handlers synchronously

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | none
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

This adds a `sync://` transport that just calls the handlers immediately. Why? This allows you to route your messages to some "async" transport. But then, when developing locally or running your tests, you can choose to run them synchronously instead:

```yml
# config/packages/messenger.yaml
framework:
    messenger:
        transports:
            async: '%env(MESSENGER_TRANSPORT_DSN)%'
        routing:
            'App\Message\SmsNotification': async
            'App\Message\OtherMessage': async
```

```
# .env
# by default, handle this sync
MESSENGER_TRANSPORT_DSN=sync://
```

```
# .env.local on production (or set this via real env vars)
# on production, use amqp
MESSENGER_TRANSPORT_DSN=amqp://.......
```

Cheers!

Commits
-------

3da5a43 Adding the "sync" transport to call handlers synchronously

symfony-splitter pushed a commit to symfony/messenger that referenced this issue Mar 31, 2019

feature #30754 [Messenger] New messenger:stop-workers Command (weaver…
…ryan)

This PR was squashed before being merged into the 4.3-dev branch (closes #30754).

Discussion
----------

[Messenger] New messenger:stop-workers Command

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | Kinda of #29451
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

o/ me again.

This requires and is built on top of #30708

When you deploy, all workers need to be stopped and restarted. That's not currently possible, unless you manually track the pids and send a SIGTERM signal. We can make that much easier :).

Now run:

```
bin/console messenger:stop-workers
```

And it will signal to all workers (even if they're distributed on other servers) that they should stop, once they finish processing their current message. This is done via a key in `cache.app`.

Cheers!

Commits
-------

58971627f5 [Messenger] New messenger:stop-workers Command

fabpot added a commit to symfony/symfony that referenced this issue Mar 31, 2019

feature #30754 [Messenger] New messenger:stop-workers Command (weaver…
…ryan)

This PR was squashed before being merged into the 4.3-dev branch (closes #30754).

Discussion
----------

[Messenger] New messenger:stop-workers Command

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | Kinda of #29451
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

o/ me again.

This requires and is built on top of #30708

When you deploy, all workers need to be stopped and restarted. That's not currently possible, unless you manually track the pids and send a SIGTERM signal. We can make that much easier :).

Now run:

```
bin/console messenger:stop-workers
```

And it will signal to all workers (even if they're distributed on other servers) that they should stop, once they finish processing their current message. This is done via a key in `cache.app`.

Cheers!

Commits
-------

5897162 [Messenger] New messenger:stop-workers Command

OskarStark added a commit to OskarStark/symfony-docs that referenced this issue Apr 1, 2019

minor symfony#11262 [Messenger] Rename the messenger:consume-messages…
… command (javiereguiluz)

This PR was merged into the master branch.

Discussion
----------

[Messenger] Rename the messenger:consume-messages command

This fixes one of the bullet points of symfony#11236.

Commits
-------

52a7157 [Messenger] Rename the messenger:consume-messages command

symfony-splitter pushed a commit to symfony/messenger that referenced this issue Apr 3, 2019

feature #30757 [Messenger] Adding MessageCountAwareInterface to get t…
…ransport message count (weaverryan)

This PR was squashed before being merged into the 4.3-dev branch (closes #30757).

Discussion
----------

[Messenger] Adding MessageCountAwareInterface to get transport message count

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | none
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

This adds a new optional interface that receivers should implement to give an approximate number of the messages "waiting" to be handled. Why? Because, with this, you could design a system that dynamically adds/removes worker processes if a specific transport is getting slammed and needs help. Creating that system could be something we discuss for core later, but this at least makes it possible - and means it could be implemented by the user or in a bundle... which I might do if we don't get it in core ;).

Commits
-------

fc5b0cf570 [Messenger] Adding MessageCountAwareInterface to get transport message count

fabpot added a commit to symfony/symfony that referenced this issue Apr 3, 2019

feature #30757 [Messenger] Adding MessageCountAwareInterface to get t…
…ransport message count (weaverryan)

This PR was squashed before being merged into the 4.3-dev branch (closes #30757).

Discussion
----------

[Messenger] Adding MessageCountAwareInterface to get transport message count

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | none
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

This adds a new optional interface that receivers should implement to give an approximate number of the messages "waiting" to be handled. Why? Because, with this, you could design a system that dynamically adds/removes worker processes if a specific transport is getting slammed and needs help. Creating that system could be something we discuss for core later, but this at least makes it possible - and means it could be implemented by the user or in a bundle... which I might do if we don't get it in core ;).

Commits
-------

fc5b0cf [Messenger] Adding MessageCountAwareInterface to get transport message count

symfony-splitter pushed a commit to symfony/messenger that referenced this issue Apr 6, 2019

feature #30008 [messenger] Adds a stamp to provide a routing key on m…
…essage publishing (G15N, sroze)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[messenger] Adds a stamp to provide a routing key on message publishing

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #29950
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

Adds a stamp allowing to set a `routing_key` at `MessageBus::dispatch()` level.

```php
$message = (new Envelope('message'))->with(new RoutingKeyStamp('routing_key'));
$bus->dispatch($message);
```

Commits
-------

a515635f18 Simply code and rename "configuration" to "options"
3151b54b7a [messenger] AMQP configurable routing key & multiple queues

sroze added a commit to symfony/symfony that referenced this issue Apr 6, 2019

feature #30008 [messenger] Adds a stamp to provide a routing key on m…
…essage publishing (G15N, sroze)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[messenger] Adds a stamp to provide a routing key on message publishing

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #29950
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

Adds a stamp allowing to set a `routing_key` at `MessageBus::dispatch()` level.

```php
$message = (new Envelope('message'))->with(new RoutingKeyStamp('routing_key'));
$bus->dispatch($message);
```

Commits
-------

a515635 Simply code and rename "configuration" to "options"
3151b54 [messenger] AMQP configurable routing key & multiple queues

symfony-splitter pushed a commit to symfony/messenger that referenced this issue Apr 28, 2019

feature #30958 [Messenger] Allows to register handlers on a specific …
…transport (sroze)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Messenger] Allows to register handlers on a specific transport

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #30110
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

With the #30008 pull-request in, we can now do the following:
```yaml
framework:
    messenger:
        transports:
            events:
                dsn: amqp://guest:guest@127.0.0.1/%2f/events
                options:
                    queues:
                        3rdparty:
                            binding_keys: [ 3rdparty ]
                        projection:
                            binding_keys: [ projection ]

            events_3rdparty: amqp://guest:guest@127.0.0.1/%2f/events?queues[3rdparty]
            events_projection: amqp://guest:guest@127.0.0.1/%2f/events?queues[projection]

        routing:
            'App\Message\RegisterBet': events
```

This will bind two queues to the `events` exchange, fantastic:
<img width="325" alt="Screenshot 2019-04-07 at 10 26 27" src="https://user-images.githubusercontent.com/804625/55680861-af373580-591f-11e9-8f1e-2d3b6ddba2fd.png">

---

Now, in this setup, the message will be duplicated within the `3rdparty` & `projection` queues. If you just run the consumer for each transport, it will consume the message and call all the handlers. You can't do different things based on which queue you have consumed the message. **This pull-request adds the following feature:**

```php
class RegisterBetHandler implements MessageSubscriberInterface
{
    public function __invoke(RegisterBet $message)
    {
        // Do something only when the message comes from the `events_projection` transport...
    }

    /**
     * {@inheritdoc}
     */
    public static function getHandledMessages(): iterable
    {
        yield RegisterBet::class => [
            'from_transport' => 'events_projection',
        ];
    }
}
```

---

In the debugger, it looks like this:
<img width="649" alt="Screenshot 2019-04-07 at 10 29 55" src="https://user-images.githubusercontent.com/804625/55680892-1d7bf800-5920-11e9-80f7-853f0201c6d8.png">

Commits
-------

f0b2acd67d Allows to register handlers on a specific transport (and get rid of this handler alias)

sroze added a commit to symfony/symfony that referenced this issue Apr 28, 2019

feature #30958 [Messenger] Allows to register handlers on a specific …
…transport (sroze)

This PR was merged into the 4.3-dev branch.

Discussion
----------

[Messenger] Allows to register handlers on a specific transport

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #30110
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

With the #30008 pull-request in, we can now do the following:
```yaml
framework:
    messenger:
        transports:
            events:
                dsn: amqp://guest:guest@127.0.0.1/%2f/events
                options:
                    queues:
                        3rdparty:
                            binding_keys: [ 3rdparty ]
                        projection:
                            binding_keys: [ projection ]

            events_3rdparty: amqp://guest:guest@127.0.0.1/%2f/events?queues[3rdparty]
            events_projection: amqp://guest:guest@127.0.0.1/%2f/events?queues[projection]

        routing:
            'App\Message\RegisterBet': events
```

This will bind two queues to the `events` exchange, fantastic:
<img width="325" alt="Screenshot 2019-04-07 at 10 26 27" src="https://user-images.githubusercontent.com/804625/55680861-af373580-591f-11e9-8f1e-2d3b6ddba2fd.png">

---

Now, in this setup, the message will be duplicated within the `3rdparty` & `projection` queues. If you just run the consumer for each transport, it will consume the message and call all the handlers. You can't do different things based on which queue you have consumed the message. **This pull-request adds the following feature:**

```php
class RegisterBetHandler implements MessageSubscriberInterface
{
    public function __invoke(RegisterBet $message)
    {
        // Do something only when the message comes from the `events_projection` transport...
    }

    /**
     * {@inheritdoc}
     */
    public static function getHandledMessages(): iterable
    {
        yield RegisterBet::class => [
            'from_transport' => 'events_projection',
        ];
    }
}
```

---

In the debugger, it looks like this:
<img width="649" alt="Screenshot 2019-04-07 at 10 29 55" src="https://user-images.githubusercontent.com/804625/55680892-1d7bf800-5920-11e9-80f7-853f0201c6d8.png">

Commits
-------

f0b2acd Allows to register handlers on a specific transport (and get rid of this handler alias)

fabpot added a commit to symfony/symfony that referenced this issue May 1, 2019

feature #30970 [Messenger] Adding failure transport support (weaverryan)
This PR was squashed before being merged into the 4.3-dev branch (closes #30970).

Discussion
----------

[Messenger] Adding failure transport support

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yes
| New feature?  | yes
| BC breaks?    | yes
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #31231
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

This adds "failure" transport support for messenger, so that messages that fail on *all* their retries can be collected in one spot and retried later if wanted:

```yml
framework:
    messenger:
        failure_transport: failed

        transports:
            async:
                dsn: 'amqp://'
            failed:
                dsn: 'doctrine://default?queue_name=failed'

        routing:
            'App\Message\SmsNotification': async
```

In this setup, `SmsNotification` would be retried 3 times on the `async` transport (current behavior) and then finally sent to the `failed` transport. The `failed` transport can be consumed like a normal transport, but should usually be handled & consumed by one of the new commands:

**> bin/console messenger:failed:show**
<img width="861" alt="Screen Shot 2019-04-10 at 3 15 45 PM" src="https://user-images.githubusercontent.com/121003/55917329-ddc54280-5ba3-11e9-878c-af3c653643de.png">

**> bin/console messenger:failed:show 217**
<img width="804" alt="Screen Shot 2019-04-10 at 3 15 55 PM" src="https://user-images.githubusercontent.com/121003/55917360-f33a6c80-5ba3-11e9-9f12-a8c57a9a7a4b.png">

**> bin/console messenger:failed:purge 217**
<img width="835" alt="Screen Shot 2019-04-10 at 3 16 07 PM" src="https://user-images.githubusercontent.com/121003/55917383-ff262e80-5ba3-11e9-9720-e24176b834f7.png">

**> bin/console messenger:failed:retry 217**
<img width="737" alt="Screen Shot 2019-04-10 at 3 16 29 PM" src="https://user-images.githubusercontent.com/121003/55917396-09482d00-5ba4-11e9-8d51-0bbe2b4ffc14.png">

**> bin/console messenger:failed:retry 218 -vv**
<img width="1011" alt="Screen Shot 2019-04-10 at 3 20 39 PM" src="https://user-images.githubusercontent.com/121003/55917503-6512b600-5ba4-11e9-9365-4ac87d858541.png">

**Note** (This screenshot is ugly - need to make the dump of the message and the exception more attractive)

Or you can run `bin/console messenger:failed:retry` without any argument, and it will consume the failed messages one-by-one and ask you if you want to retry/handle each. By passing

Cheers!

Commits
-------

36487e5 [Messenger] Adding failure transport support

fabpot added a commit to symfony/symfony that referenced this issue May 11, 2019

bug #31425 [Messenger] On failure retry, make message appear received…
… from original sender (weaverryan)

This PR was squashed before being merged into the 4.3 branch (closes #31425).

Discussion
----------

[Messenger] On failure retry, make message appear received from original sender

| Q             | A
| ------------- | ---
| Branch?       | master (4.3)
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #31413
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

Fixes a bug when using the transport-based handler config from #30958. This also adds a pretty robust integration test that dispatches a complex message with transport-based handler config, failures, failure transport, etc - and verifies the correct behavior.

Cheers!

Commits
-------

80b5df2 [Messenger] On failure retry, make message appear received from original sender

symfony-splitter pushed a commit to symfony/messenger that referenced this issue May 11, 2019

bug #31425 [Messenger] On failure retry, make message appear received…
… from original sender (weaverryan)

This PR was squashed before being merged into the 4.3 branch (closes #31425).

Discussion
----------

[Messenger] On failure retry, make message appear received from original sender

| Q             | A
| ------------- | ---
| Branch?       | master (4.3)
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #31413
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

Fixes a bug when using the transport-based handler config from #30958. This also adds a pretty robust integration test that dispatches a complex message with transport-based handler config, failures, failure transport, etc - and verifies the correct behavior.

Cheers!

Commits
-------

80b5df270f [Messenger] On failure retry, make message appear received from original sender

symfony-splitter pushed a commit to symfony/framework-bundle that referenced this issue May 11, 2019

bug #31425 [Messenger] On failure retry, make message appear received…
… from original sender (weaverryan)

This PR was squashed before being merged into the 4.3 branch (closes #31425).

Discussion
----------

[Messenger] On failure retry, make message appear received from original sender

| Q             | A
| ------------- | ---
| Branch?       | master (4.3)
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #31413
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

Fixes a bug when using the transport-based handler config from #30958. This also adds a pretty robust integration test that dispatches a complex message with transport-based handler config, failures, failure transport, etc - and verifies the correct behavior.

Cheers!

Commits
-------

80b5df270f [Messenger] On failure retry, make message appear received from original sender

fabpot added a commit to symfony/symfony that referenced this issue May 11, 2019

feature #31454 [Messenger] remove send_and_handle which can be achiev…
…ed with SyncTransport (Tobion)

This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] remove send_and_handle which can be achieved with SyncTransport

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | no
| New feature?  | yes/no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | yes     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets |
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

The send_and_handle option is pretty awkward and we don't need it anymore because the same thing can be achieved with the SyncTransport from #30759

So the following example from the doc in https://symfony.com/doc/current/messenger.html#routing
```yaml
framework:
    messenger:
        routing:
            'My\Message\ThatIsGoingToBeSentAndHandledLocally':
                 senders: [amqp]
                 send_and_handle: true
```
is the same as
```yaml
framework:
    messenger:
        routing:
            'My\Message\ThatIsGoingToBeSentAndHandledLocally':
                 senders: [amqp, sync]
```

#31401 (review)

Commits
-------

4552b7f [Messenger] remove send_and_handle option which can be achieved with SyncTransport

symfony-splitter pushed a commit to symfony/messenger that referenced this issue May 11, 2019

feature #31454 [Messenger] remove send_and_handle which can be achiev…
…ed with SyncTransport (Tobion)

This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] remove send_and_handle which can be achieved with SyncTransport

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | no
| New feature?  | yes/no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | yes     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets |
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

The send_and_handle option is pretty awkward and we don't need it anymore because the same thing can be achieved with the SyncTransport from #30759

So the following example from the doc in https://symfony.com/doc/current/messenger.html#routing
```yaml
framework:
    messenger:
        routing:
            'My\Message\ThatIsGoingToBeSentAndHandledLocally':
                 senders: [amqp]
                 send_and_handle: true
```
is the same as
```yaml
framework:
    messenger:
        routing:
            'My\Message\ThatIsGoingToBeSentAndHandledLocally':
                 senders: [amqp, sync]
```

symfony/symfony#31401 (review)

Commits
-------

4552b7f5b2 [Messenger] remove send_and_handle option which can be achieved with SyncTransport

symfony-splitter pushed a commit to symfony/framework-bundle that referenced this issue May 11, 2019

feature #31454 [Messenger] remove send_and_handle which can be achiev…
…ed with SyncTransport (Tobion)

This PR was merged into the 4.3 branch.

Discussion
----------

[Messenger] remove send_and_handle which can be achieved with SyncTransport

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | no
| New feature?  | yes/no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks?    | yes     <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets |
| License       | MIT
| Doc PR        | symfony/symfony-docs#11236

The send_and_handle option is pretty awkward and we don't need it anymore because the same thing can be achieved with the SyncTransport from #30759

So the following example from the doc in https://symfony.com/doc/current/messenger.html#routing
```yaml
framework:
    messenger:
        routing:
            'My\Message\ThatIsGoingToBeSentAndHandledLocally':
                 senders: [amqp]
                 send_and_handle: true
```
is the same as
```yaml
framework:
    messenger:
        routing:
            'My\Message\ThatIsGoingToBeSentAndHandledLocally':
                 senders: [amqp, sync]
```

symfony/symfony#31401 (review)

Commits
-------

4552b7f5b2 [Messenger] remove send_and_handle option which can be achieved with SyncTransport
@Tobion

This comment has been minimized.

Copy link
Member

commented May 11, 2019

- [X] send_and_handle messenger routing got removed in favor of SyncTransport symfony/symfony#31454

(note from Ryan): I moved this up into the main list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.