Deploy #702 PR3b (#1832) only 24h after the attempt journal (#1824, 000161) is live in each environment #1835

Summary

#1832 (#702 PR3b) lifts the refusal of Redshift re-drive and Retry. A Redshift purchase row dispatched before the attempt journal (#1824, migration 000161) was live in an environment has no journal record. If AWS changes that tuple's offering within the 24h re-drive horizon, a retry of such a row could buy a second reserved node. So in every environment, #1832 must be deployed no earlier than 24h after #1824 and 000161 are live there.

Dev is handled by merge timing: #1824 went live on dev at 2026-11-06T23:38:42Z, so #1832 merges no earlier than 2026-11-07T23:39Z. Prod deploys separately, so the same rule needs an explicit runbook step.

Steps to verify the gap

1. Check the prod deploy runbook and known_issues/: neither records the 24h ordering between feat(purchase): record Redshift purchase attempts in a durable journal #1824 (and 000161) and fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832.
2. A prod release that ships feat(purchase): record Redshift purchase attempts in a durable journal #1824 and fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832 together, or ships fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832 within 24h of feat(purchase): record Redshift purchase attempts in a durable journal #1824, would open the window.

Expected behaviour

The prod (and any other environment's) release process makes sure #1832 is deployed at least 24h after #1824 and migration 000161 are live in that environment.

Proposed fix

• Add a step to the deploy runbook for releases that include fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832: confirm 000161 and feat(purchase): record Redshift purchase attempts in a durable journal #1824 have been live in the target environment for at least 24h before deploying fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832.
• Add one line to known_issues/39_redshift_dedupe_window.md recording the ordering and why.
• Optional, for a later change: a fail-closed check that refuses a Redshift retry of a row whose first dispatch predates the environment's journal start time.

References

• fix(purchase): Redshift reserved-node purchases without tag-based idempotency #702, fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832 (PR3b), feat(purchase): record Redshift purchase attempts in a durable journal #1824 (attempt journal), migration 000161.
• The deploy-order risk was raised in the fix(purchase): allow Redshift re-drive behind the retry, lineage and journal gates #1832 review.

Severity

Medium (money path: a possible duplicate purchase in a narrow deploy window).

🤖 Generated with Claude Code