fix(checkout-api): resolve checkout-race-condition

[Spkap]

Summary

Resolve checkout-race-condition for checkout-api with a validated ReplayX patch candidate.

Changed Files

• demo_app/src/inventory/reserve-stock.ts
• demo_app/src/checkout/submit-order.ts

Validation

• Concurrent checkout repro: exit 0
• Sequential checkout sanity: exit 0

Rollback

Revert the live inventory guard and concurrent checkout settlement handling.

[Copilot]

Pull request overview

This PR addresses the checkout-race-condition incident in the demo app by preventing overselling during concurrent checkouts and ensuring the concurrent repro path no longer fails due to expected “out of stock” rejections.

Changes:

• Add a post-delay availability guard in reserveStock to prevent committing negative inventory under concurrency.
• Generate reservation metadata (token + snapshotVersion) from the committed inventory record state.
• Update the concurrent checkout repro to tolerate expected OutOfStock failures via Promise.allSettled.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
demo_app/src/inventory/reserve-stock.ts	Adds a post-delay availability check and returns reservation metadata based on the committed record state.
demo_app/src/checkout/submit-order.ts	Uses Promise.allSettled and filters expected out-of-stock rejections to keep the concurrent repro from failing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The inline comment describing the post-snapshot delay as an “Intentional bug” is now misleading because the new post-delay record.available < quantity guard prevents the stale pre-check from causing an oversell. Please update/remove the comment so future readers don’t think the race is still intentionally present (or clarify that the delay is retained only to simulate concurrency while remaining safe).

[Copilot]

runCheckoutRaceScenario classifies “expected” failures by string-matching Error.message.startsWith("OutOfStock:"). This is brittle (message format changes will flip behavior) and couples control flow to human-readable text. Consider using a dedicated error type or a stable discriminator (e.g., error.name / code property) from reserveStock, and check that instead.