The raven leaves, that's something. But it leaves during the request: the guild's scroll waits for the bird to be prepared, fed and released before getting its answer. And if the aviary is crowded, the guild waits.
From now on, the message will go into a queue. The response leaves at once; a worker takes care of the ravens at its own pace.
Your mission
In config/packages/messenger.yaml:
- declare an
asynctransport, which keeps the messages in the database (doctrine://default); - route
App\Message\ConfirmationDemandeeto this transport; - during the tests, replace this transport with
in-memory://.
Nothing to change in the message, the handler or the controller: that's the whole point.
See the queue, then empty it
Book from the “Requests” tab: the aviary (/aviary) stays empty, the raven is waiting. In the Console tab:
messenger:stats messenger:consume async --limit=1
The first command counts the waiting messages, the second handles one and then stops. Reload the aviary: the raven has left.
In production, this messenger:consume runs all the time, watched over by a supervisor.
Why in-memory:// during the tests?
A test must neither write to the real queue nor depend on a worker. The in-memory:// transport keeps the messages in the test's memory: you can check that a message was sent, and handle it whenever you choose.
Good to know
The doctrine://default DSN creates its table by itself on the first message. In production, you'd rather use ?auto_setup=0 and a messenger:setup-transports command at deployment time: the application does not change the database while it is running.