deliveries.wrong_state
A delivery or schedule run was asked to do something its state rules out, such as cancelling one that has already failed.
Area 14, Tools; not declinable; the next step is usually the human's.
Why Jadpo refuses it
Each action of jadpo deliveries applies to items in some states only:
retry and dismiss to one that failed, cancel to one still waiting
to run, and resolve to one whose outside call may or may not have
happened. An action that doesn't apply to an item as it is would do
nothing, or the wrong thing: cancelling a delivery that already failed
stops nothing. So nothing is done, and the error says what state the
item is in and what applies to it.
Jadpo won't do the action that applies instead: whether a failed delivery is sent again or set aside decides what the app does for the person it was for.
What it looks like
A project where adding a note emits NoteAdded, which the subscriber
share_added delivers to share_note. Until there is a team to share
with, share_note fails, and share_added tries once:
domains/notes/subscribers/share_added.jadpo:
use notes/actions { share_note }use notes/events { NoteAdded }/// Shares each note once it is written down.subscriber share_added { on: NoteAdded run: share_note(event.note_id) retry: { attempts: 1 }}
Each delivery's id is random, so a run prints a different id every time
and can't be checked; this output is copied from a real run. It is
jadpo deliveries on a Mac, with DATABASE_URL naming a new PostgreSQL
database after jadpo migrate apply and the seed demo wrote a note,
whose delivery failed, then cancel on that delivery:
jadpo deliveriesjadpo deliveries cancel dc0f8b4c
id item state last tried (UTC) dc0f8b4c NoteAdded → share_added x failed 21:06:21 · no_teamdeliveries need attention: 1 failednext: jadpo deliveries retry dc0f8b4c sends it again, once the cause is fixederror: `dc0f8b4c` isn't pending, so there is nothing to cancel reason: Its delivery of `NoteAdded` to `share_added` failed. Cancel stops a delivery, or a run asked for by hand, that is waiting to run. next: Run `jadpo deliveries retry dc0f8b4c`, or `jadpo deliveries dismiss dc0f8b4c` (human) rule: deliveries.wrong_state help: https://jadpo.dev/docs/errors/deliveries.wrong_state
(human) at the end of the next: line tells your coding agent to stop
and ask you which fix you want, because the choice is yours to make: it
decides whether the note is shared after all.
How to fix it
The question is whether the delivery should go again.
If it should, once its cause is fixed, retry it:
jadpo deliveries retry dc0f8b4cThe delivery is pending again, with a fresh retry budget, and the app's next tick sends it.
If it shouldn't go at all, dismiss it:
jadpo deliveries dismiss dc0f8b4cshare_added never receives that NoteAdded, and the delivery is
listed under jadpo deliveries --state dismissed, with who dismissed it.
Related
Markdown for agents: /docs/errors/deliveries.wrong_state.md.Built from Jadpo main at aee2e8f.