Summary
Answering a pending decision (a nudge reply, or a task blocked via --question) sometimes does not resume the job/session that actually asked. Instead, a separate, freshly-dispatched worker job executes the now-approved action, while the original job stays alive and unaware — and can later independently re-execute the same action.
Impact
Two live workers can end up holding authorization to perform the same state-changing action at the same time. Observed twice in two days, via two different trigger paths:
Case 1 — nudge reply races task dispatch. A job blocked a task with --question and also opened a decision-kind nudge tied to itself, both asking the same approval. The human tapped an option on the nudge (recorded correctly as channel: inbox, "Human replied: " on the nudge). About two minutes later, a different, newly-dispatched job executed the approved plan and closed the task — never having received the nudge reply itself. The original job, still alive and still waiting, was only resumed over an hour later (by an unrelated follow-up nudge) and, unaware the work was already done, redundantly repeated the approved action against an already-updated system. No lasting damage that time only because the action happened to be idempotent.
Case 2 — chained task pre-empts the reply. A job asked via nudge whether to proceed with a two-step change, got a "yes," then asked a follow-up question. Before the reply to that follow-up could resume the job, a separate follow-up task (chained to start once the first task's prerequisite was satisfied) auto-launched its own worker, which independently completed the full change, including the part still pending the human's answer. The human's actual reply then landed on a job whose work was already done. (The platform surfaced this one itself, via a nudge titled "... a parallel job beat me to your answer.")
Expected behavior
Replying to a nudge, or answering a task's --question block, should deterministically resume the exact job/session that created it — never trigger a second, independent worker to act on the same pending approval.
Suspected trigger conditions
- A task that is simultaneously (a) blocked with
--question and (b) has an open decision/approval nudge tied to the same job.
- A task chained with
--after whose prerequisite becomes satisfied while a different, still-open decision on the parent task hasn't been answered yet — the chained task's own dispatch can complete work that overlaps with what the still-waiting job hasn't done.
Why this matters
For state-changing, outward-facing actions (the kind that require explicit approval in the first place), a duplicate/racing execution is a real safety hazard, not just a wasted job — especially for anything that isn't naturally idempotent.
Environment
- Clockwork 0.2.49 (macOS)
one-run CLI 0.0.1 / one CLI 1.55.4
Summary
Answering a pending decision (a nudge reply, or a task blocked via
--question) sometimes does not resume the job/session that actually asked. Instead, a separate, freshly-dispatched worker job executes the now-approved action, while the original job stays alive and unaware — and can later independently re-execute the same action.Impact
Two live workers can end up holding authorization to perform the same state-changing action at the same time. Observed twice in two days, via two different trigger paths:
Case 1 — nudge reply races task dispatch. A job blocked a task with
--questionand also opened adecision-kind nudge tied to itself, both asking the same approval. The human tapped an option on the nudge (recorded correctly aschannel: inbox, "Human replied: " on the nudge). About two minutes later, a different, newly-dispatched job executed the approved plan and closed the task — never having received the nudge reply itself. The original job, still alive and still waiting, was only resumed over an hour later (by an unrelated follow-up nudge) and, unaware the work was already done, redundantly repeated the approved action against an already-updated system. No lasting damage that time only because the action happened to be idempotent.Case 2 — chained task pre-empts the reply. A job asked via nudge whether to proceed with a two-step change, got a "yes," then asked a follow-up question. Before the reply to that follow-up could resume the job, a separate follow-up task (chained to start once the first task's prerequisite was satisfied) auto-launched its own worker, which independently completed the full change, including the part still pending the human's answer. The human's actual reply then landed on a job whose work was already done. (The platform surfaced this one itself, via a nudge titled "... a parallel job beat me to your answer.")
Expected behavior
Replying to a nudge, or answering a task's
--questionblock, should deterministically resume the exact job/session that created it — never trigger a second, independent worker to act on the same pending approval.Suspected trigger conditions
--questionand (b) has an opendecision/approvalnudge tied to the same job.--afterwhose prerequisite becomes satisfied while a different, still-open decision on the parent task hasn't been answered yet — the chained task's own dispatch can complete work that overlaps with what the still-waiting job hasn't done.Why this matters
For state-changing, outward-facing actions (the kind that require explicit approval in the first place), a duplicate/racing execution is a real safety hazard, not just a wasted job — especially for anything that isn't naturally idempotent.
Environment
one-runCLI 0.0.1 /oneCLI 1.55.4