[Messenger] Add the transports documentation #9756
Conversation
| $this->toEmail = $toEmail; | ||
| } | ||
|
|
||
| public function send($message) |
There was a problem hiding this comment.
Should be updated according to the current contract, Envelope $... ?
|
|
||
| class YourTransport implements TransportInterface | ||
| { | ||
| public function send($message) : void |
|
|
||
| First, create your sender:: | ||
|
|
||
| namespace App\MessageSender; |
There was a problem hiding this comment.
We could go suggesting a better structure for Messenger stuff? maybe App\Message\Sender or App\Messenger\Transport instead?
| ~~~~~~~~~~~~~~ | ||
|
|
||
| If something wrong happens (i.e. an exception is thrown) while handling your message, | ||
| the default behaviour is that your message will be "NACK" and requeued. |
There was a problem hiding this comment.
Who is NACK? It sounds mean :).
Seriously, as someone not too familiar with this stuff, is NACK an "action". Like, a "message is NACKed"? OR, something different?
There was a problem hiding this comment.
Not Acknowledge. Do you have any idea on how to phrase it differently? 🤷♂️
There was a problem hiding this comment.
Beginning with this, i'll explain this like : Not Acknowledge = not treated and requeued.
components/messenger/transports.rst
Outdated
| Retry | ||
| ~~~~~ | ||
|
|
||
| When receiving messages from a broker, it might happen that some exceptions will |
There was a problem hiding this comment.
I'm not clear what this means. Do you mean, when my app is handling a message (that just came from a broker), it could fail (e.g. DB exception, or my handler throws an exception)? Or, are you talking about some sort of communication error from the broker?
| the first failure, it will wait 10 seconds before trying it. After the 2nd failure, | ||
| it will wait 30 seconds. After the 3rd failure, it will wait a minute. If it still | ||
| fails, the message will be moved to a "dead queue" and you will have to manually | ||
| handle this message. |
There was a problem hiding this comment.
Can you just define a single TTL to be used for each retry? Or is there a default?
There was a problem hiding this comment.
These are to be removed as retry wasn't merged in.
components/messenger/transports.rst
Outdated
| When receiving messages from a broker, it might happen that some exceptions will | ||
| arise. Typically, a 3rd party provider is down or your system is under heavy load | ||
| and can't really process some messages. To handle this scenario, there is a built-in | ||
| retry mechanism that can be enabled via your DSN:: |
There was a problem hiding this comment.
You can't use the :: in these cases - it's short for .. code-block:: php, and it's just text below. Let's use:
.. code-block:: text
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| The options available in the DSN are documented on the ``Connection`` class | ||
| in the code repository. |
There was a problem hiding this comment.
| ~~~~~~~~~~~~~~ | ||
|
|
||
| If something wrong happens (i.e. an exception is thrown) while handling your message, | ||
| the default behaviour is that your message will be "NACK" and requeued. |
There was a problem hiding this comment.
Not Acknowledge. Do you have any idea on how to phrase it differently? 🤷♂️
|
|
||
| First, create your sender:: | ||
|
|
||
| namespace App\MessageSender; |
| the first failure, it will wait 10 seconds before trying it. After the 2nd failure, | ||
| it will wait 30 seconds. After the 3rd failure, it will wait a minute. If it still | ||
| fails, the message will be moved to a "dead queue" and you will have to manually | ||
| handle this message. |
There was a problem hiding this comment.
These are to be removed as retry wasn't merged in.
|
Anyone with experience in Messenger is willing to do the final push required to finish this pull request? Thanks! |
|
Thank you very much for your pull request! As part of the Symfony EU funded hackathon (https://symfony.com/blog/the-symfony-and-api-platform-hackathon-is-coming), we were able to assemble most of the core team and big contributors in one place. Our goal is to finish as many open issues and PRs as possible. Your commits will not be lost and you will therefore get credit for your work. All that will happen is that your commits will be moved to a new PR where all remaining concerns will be addressed. Without your work this would not have been possible. So thank you once again! |
|
Thank you @llaakkkk 🙌 |
Add the Messenger transports documentation. Does not aim to be exhaustive but give more details.
One little thing... we wait for this one to be merged: symfony/symfony#27008