Context
Agentic orchestrators run multi-step, side-effecting build sequences. Example from the FIIA Scaffold Kit (EXEC-CLONE): ~15 steps execute under a single resume checkpoint — two sync pushes, T11/T12 bootstrap job runs, variables-set, token encrypt, semantic-layer import, and a setup-flow run. On crash / interruption + resume, the whole block is replayed.
Problem
JobService.run_job() (verified in the v0.62.0 signature) has no client-supplied idempotency key, so a replayed run creates a duplicate job / re-fires the side effect. The consumer is forced to hand-roll "did this already run?" probes before every job, which is brittle.
(For contrast: sync push re-push is already idempotent since 0.47.0 — thanks. This request is specifically about job runs and an explicit dedup token.)
Request
An optional client-supplied idempotency_key on run_job() (and ideally push()), such that a replayed call with the same key returns the prior job/result instead of creating a duplicate side effect.
Implementation could be:
- client-side: a small dedup store keyed by
idempotency_key → job id, or
- pass-through to the Queue API if/where it supports request de-duplication.
Benefit
Lets agentic consumers make their resume paths safe declaratively, instead of re-implementing existence probes before each side-effecting call. Directly reduces the "replay re-runs bootstrap jobs against a live project" failure class.
Context
Agentic orchestrators run multi-step, side-effecting build sequences. Example from the FIIA Scaffold Kit (
EXEC-CLONE): ~15 steps execute under a single resume checkpoint — twosync pushes, T11/T12 bootstrap job runs,variables-set, token encrypt, semantic-layer import, and a setup-flow run. On crash / interruption + resume, the whole block is replayed.Problem
JobService.run_job()(verified in the v0.62.0 signature) has no client-supplied idempotency key, so a replayed run creates a duplicate job / re-fires the side effect. The consumer is forced to hand-roll "did this already run?" probes before every job, which is brittle.(For contrast:
sync pushre-push is already idempotent since 0.47.0 — thanks. This request is specifically about job runs and an explicit dedup token.)Request
An optional client-supplied
idempotency_keyonrun_job()(and ideallypush()), such that a replayed call with the same key returns the prior job/result instead of creating a duplicate side effect.Implementation could be:
idempotency_key→ job id, orBenefit
Lets agentic consumers make their resume paths safe declaratively, instead of re-implementing existence probes before each side-effecting call. Directly reduces the "replay re-runs bootstrap jobs against a live project" failure class.