In prepare_checkpoint_for_resume the resume_job lookup took the oldest row
for the job (ORDER BY created_at ASC LIMIT 1), so a WAC workflow with
multiple sequential wait_for_approval() calls always read the first
approval's result for every step. Consumed rows are never deleted, so the
2nd and 3rd approvals inherited the 1st's result (all showed approved:true
even if the 2nd was cancelled and the 3rd timed out).
Track the resume_job row ids consumed by earlier approval steps in the
checkpoint (consumed_resume_ids) and exclude them, so each step reads its
own row. This is channel-agnostic and needs no clock reasoning:
resume_job.resume_id is only hash(step_key) for the inline resume URL; the
approval page, the in-run approve button, Slack, Teams and resume-as-owner
all store a random resume_id, so filtering by resume_id would drop those
approvals and return approved:false even for a legitimate approval. A
timed-out step matches no row and still falls to the else branch returning
{approved: false}.
Adds a regression test driving three sequential approvals (approved,
cancelled, timed-out) against Postgres.
Fixes WIN-2241
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ruben Fiszel
2143d45815