Post

Been bitten by exactly the "reliable job lifecycle" line before - looks solid right up until two retries land on the same task and the handler turns out not to be idempotent. How are you handling dedup in the workers when a retry doubles up?

THanks for asking ! The workers don't dedup. They're stateless and never touch the DB : they just fire HTTP callbacks to a single writer (the Rust API) that owns idempotency via guarded state transitions + replace/upsert, not a dedup table.

Makes sense money's the one thing you left non-idempotent. A retry really did spend the tokens again, so guarding it just hides real cost. Workers staying dumb while one writer owns every transition is the part I'd steal. For the at-least-once webhooks, do consumers get an event id to dedup on?

So when a task redelivers and re runs : results are written DELETE then INSERT, agent-journal steps upsert ON CONFLICT (job_id, seq) DO NOTHING, and status transitions are guarded (started only from pending, a late failure never clobbers a completed).