What a newcomer hits
I started my first workflow, watched durable_events get its first rows, and then watched nothing else happen. The execution was suspended, correctly, waiting for a resume that no process was going to deliver.
The dashboard says RUNNING. That is true and unhelpful: it is running in the sense that it has not finished, not in the sense that anything is working on it.
The fix is obvious once you know it:
bin/console messenger:consume durable_workflows durable_activities
The queue names come from the transports I invented, in the config I wrote, because there is no recipe. So the command that makes the library work cannot be copied from any document - you have to already know your own naming.
Ask
A first-party command:
bin/console durable:worker
It knows its own transports - the bundle configured them - and needs no arguments. Options can mirror messenger:consume (--limit, --time-limit, --memory-limit).
Two things it could do that messenger:consume cannot:
- Refuse to start when a durable message is routed to
sync. Same check as the compile-time one in the companion issue, but at the moment someone is looking.
- Say what it consumes on boot.
Consuming durable_workflows, durable_activities. One line, and the "why is nothing happening" question answers itself.
Smaller, related
The dashboard could distinguish suspended, waiting on a timer or signal from queued, and nobody has picked it up. It already tells those apart inside a run - the hatched bar means "asked for, not started" - but the run list shows both as RUNNING. A run whose next resume has been sitting in the queue for an hour is the single most useful thing an operator could be shown, and it is derivable from what the journal already holds.
What a newcomer hits
I started my first workflow, watched
durable_eventsget its first rows, and then watched nothing else happen. The execution was suspended, correctly, waiting for a resume that no process was going to deliver.The dashboard says
RUNNING. That is true and unhelpful: it is running in the sense that it has not finished, not in the sense that anything is working on it.The fix is obvious once you know it:
The queue names come from the transports I invented, in the config I wrote, because there is no recipe. So the command that makes the library work cannot be copied from any document - you have to already know your own naming.
Ask
A first-party command:
It knows its own transports - the bundle configured them - and needs no arguments. Options can mirror
messenger:consume(--limit,--time-limit,--memory-limit).Two things it could do that
messenger:consumecannot:sync. Same check as the compile-time one in the companion issue, but at the moment someone is looking.Consuming durable_workflows, durable_activities.One line, and the "why is nothing happening" question answers itself.Smaller, related
The dashboard could distinguish suspended, waiting on a timer or signal from queued, and nobody has picked it up. It already tells those apart inside a run - the hatched bar means "asked for, not started" - but the run list shows both as
RUNNING. A run whose next resume has been sitting in the queue for an hour is the single most useful thing an operator could be shown, and it is derivable from what the journal already holds.