Rollback

Rollback path depends on failure type.

Configuration rollback

Use when problem came from:

• wrong webhook secret
• wrong API key deployment
• wrong market visibility mode
• wrong wallet adapter config

Flow:

1. stop new risky traffic if needed
2. restore last known-good config
3. run focused smoke checks
4. replay failed webhooks only after fix confirmed

For Polyflight, configuration rollback means disabling new operator entry. Continue payouts, refunds, compensation, reconciliation, webhooks, and report reads for existing obligations.

Application rollback

Use when operator-side code broke signature verification, raw-body handling, wallet adapter responses, or idempotency/ambiguous-response handling.

For Opinion-only traffic, deploy the previous compatible stable version and run focused non-money checks before money probes.

For Polyflight, never deploy a version that cannot read and process polyflight-v5, native tickets, wallet obligations, or native statements while any such records exist. Use the last v5-capable build or forward-fix. Reverting future generation policy does not rewrite existing flights.

Incident guardrails

• do not replay money-related requests blindly
• do not create new idempotency keys for the same business action during investigation
• do not rotate multiple variables at once unless compromise is confirmed
• do not drop/reverse Polyflight tables, commitments, events, obligations, or finalized statements as traffic rollback
• do not change committed valuation, snapshot, result, payout, or ticket terms

After rollback

• collect failing IDs and timestamps
• compare last good vs first bad change
• update troubleshooting docs if new failure mode discovered
• reconcile all existing Polyflight liabilities and ambiguous effects
• verify statement/export parity and preserve proof/audit evidence