Skip to content

[Messenger] Added documentation about DispatchAfterCurrentBusMiddleware #10015

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.

Sign up for GitHub

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

Closed
wants to merge 13 commits into from
Closed

[Messenger] Added documentation about DispatchAfterCurrentBusMiddleware #10015

Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
8107340
Added documentation about message recorder
Nyholm Jul 4, 2018
66fc600
According to feedback
Nyholm Jul 5, 2018
091040f
a user
Nyholm Jul 5, 2018
0a3ccf6
Added fixes
Nyholm Aug 26, 2018
b5921bf
Explain HandleMessageInNewTransaction middleware
gubler Feb 24, 2019
aba0edf
Minor updates
Nyholm Mar 17, 2019
9b589ff
Added PHP and XML config
Nyholm Apr 8, 2019
0e1e0dd
Update messenger/message-recorder.rst
OskarStark Apr 8, 2019
aa4096f
Update messenger/message-recorder.rst
OskarStark Apr 8, 2019
636de55
Update messenger/message-recorder.rst
OskarStark Apr 8, 2019
157d3f0
Update messenger/message-recorder.rst
OskarStark Apr 8, 2019
6b71ef8
updates according to feedback
Nyholm Apr 8, 2019
45245df
minor updates according to feedback
Nyholm Apr 28, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
According to feedback
  • Loading branch information
@Nyholm
Nyholm committed Apr 8, 2019
commit 66fc600109637e13006440dbf7577dca35e66efb
13 changes: 9 additions & 4 deletions messenger/message-recorder.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,15 +4,15 @@
Record Events Produced by a Handler
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be better to find a name that describes the problem than the technical solution. Something like "Event recorder: Tolerating failures while in Doctrine transactions"?

===================================

In a example application there is a command (a CQRS message) named ``CreateUser``.
That command is handled by the ``CreateUserHandler``. The command handler creates
In an example application there is a command (a CQRS message) named ``CreateUser``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

- In an example application there is a command (a CQRS message) named ``CreateUser``.
+ Let's take the example of an application that has a command (a CQRS message) named ``CreateUser``.

?

That command is handled by the ``CreateUserHandler`` which creates
a ``User`` object, stores that object to a database and dispatches an ``UserCreatedEvent``.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"a UserCreatedEvent"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost :) I'm not native. But you wrote "a User" just before. See https://english.stackexchange.com/questions/105116/is-it-a-user-or-an-user

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say that "a User" was a typo.

I read your source. I did not know that. Thank you. I've updated the PR.

That event is also a normal message but is handled by an *event* bus.

There are many subscribers to the ``UserCreatedEvent``, one subscriber may send
a welcome email to the new user. Since we are using the ``DoctrineTransactionMiddleware``
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to split the two and explicit the "problem":

- Since we are using the ``DoctrineTransactionMiddleware`` [...]
+ We are using the ``DoctrineTransactionMiddleware`` to wrap all database queries in one database transaction.
+
+ **Problem:** if an exception is thrown when sending the welcome email, then the user will not be created because the ``DoctrineTransactionMiddleware`` will rollback the Doctrine transaction, in which the user has been created.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Thank you

we wrap all database queries in one database transaction and rollback that transaction
if an exception is thrown. That would mean that if an exception is thrown when sending
if an exception is thrown. That means that if an exception is thrown when sending
the welcome email, then the user will not be created.

The solution to this issue is to not dispatch the ``UserCreatedEvent`` in the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, I'd highlight the solution:

**Solution:**

Expand All @@ -27,7 +27,7 @@ in the middleware chain.

.. code-block:: yaml

# config/packages/workflow.yaml
# config/packages/messenger.yaml
framework:
messenger:
default_bus: messenger.bus.command
Expand All @@ -45,6 +45,11 @@ in the middleware chain.

.. code-block:: php

namespace App\Messenger\CommandHandler;

use App\Entity\User;
use App\Messenger\Command\CreateUser;
use App\Messenger\Event\UserCreatedEvent;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Component\Messenger\MessageRecorderInterface;

Expand Down