Stage each paid order before payment, and harden the whole flow

[stefan-burke]

This adds staged checkout and hardens it end to end — including everything from the follow-up review (items 1–10) and every automated review finding. It targets main directly and folds in the earlier fix/committed-booking-refunds work, so it is one standalone change.

What staged checkout does

When someone pays, we now write their order to the database before sending them to the card page — as an attendee with quantity-zero booking rows plus a checkout_stages record. When the payment lands, it claims those exact rows and gives them their real quantities in one atomic step. No seat is ever held while someone pays: the first payment to land wins, and holding seats would invite bots (this is now written policy in AGENTS.md).

This closes the window where a completed payment could arrive and find no record to attach to. Every outcome — a ticket, a refund, or an order the operator must look at — has one place to resolve and one record already there to carry the result.

An unbookable order never reaches the card page

Before creating the provider session, we check the order still fits and every listing is still on sale. If not, the customer is told plainly ("Sorry, this can no longer be booked…") instead of paying and being refunded. The real capacity decision still happens at activation, with the real quantities.

How failures end safely

• Changed booking lines (all rows still quantity zero, nothing live) take the keep-and-refund path with a clear reason.
• Rows already given a real quantity may be a live booking, so that becomes a no-refund operator conflict: a loud alert, a note saying exactly what to check, and the received money posted on its own — the books say "we hold this customer's money" while the operator decides.
• Transient errors retry on the provider's next delivery. A refund or ledger write that fails leaves the stage pending, so the retry re-runs the whole path; a settled refund reads back as success, so nothing refunds twice.
• Money is recorded before it is exposed. The payment reference is stamped onto the record only after the ledger holds the money, so the refund button can never appear for a charge the books haven't seen — and the crash-heal path writes the reference back if an interruption lost it.
• A stage pointing at a deleted attendee, or a staged attendee with no rows, is an impossible state and fails loudly instead of being papered over.

Mid-payment records are locked, and say so

• The record page hides the Edit, Logistics, and Actions tabs while a checkout is pending (their URLs return "not found"), with a banner: "Checkout pending: the customer may still be paying."
• Every attendee table shows "Payment in progress" instead of "No quantity", and CSV exports gain a "Checkout pending" column when any exported row is mid-payment.
• Edits, merges, and deletes fail closed with a plain message. A record holding unreturned conflict money can't be deleted, merged, or stripped of its last line until the money is refunded.
• A listing can't be deleted while it has a pending checkout — and if a delete races past that check, the pending order's rows survive and show as a read-only "Deleted listing" line, so the operator always sees what the customer paid for.
• A note's link to the owner-only ledger pages shows as plain text to other admins — no link that only fails.

Provider lifecycle

• The cancel page discards the staged details and closes the provider session, so an old tab can't pay for a checkout we no longer hold.
• Stripe checkouts get a hard deadline (CHECKOUT_SESSION_EXPIRY_MINUTES, default 60); expired checkouts are discarded the moment Stripe reports them. SumUp checkouts that lapse take the same discard-and-try-again path as a declined card.
• Setting up Stripe now removes any stray webhook endpoints already pointing at this site (left by a lost setup or a database restore) — a stray would fail signature checks on every delivery forever.

One accepted edge, by the owner's call

A paid checkout whose processing keeps failing for days could eventually have its staged record cleaned up. The money is never lost (it stays with the provider), and the operator is alerted on every failing delivery for days first — so this is documented in TODO.md rather than coded around.

Shared mechanisms

One attendee-purge mechanism now serves the single delete, the orphan purge, and the pending-checkout discard; one primary-pinned batch guard serves every mutation check; plus queryAllPrimary/queryOnePrimary, matchingIdSet, and one shared attendee-echo projection.

Verification

• deno task precommit passes in full (typecheck including tests, strict lint, complete suite, 0% duplication, 100% line and branch coverage).
• Every fix ships with a regression test that failed before it.
• Every automated review thread is answered on this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018pdUrVrzMwSgWMxdAn4qmu

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

The PR hardens staged-checkout activation and recovery, blocks administrative mutations during pending payment, improves staged-row cleanup and lookup behavior, adds structured conflict/refund outcomes, standardizes attendee projections, and aligns Stripe checkout expiry with webhook and cancellation cleanup.

Changes

Staged-checkout hardening

Layer / File(s)	Summary
Hardening plan and outcome contracts plan.md, TODO.md, src/features/api/payment-processing/*, src/shared/db/attendees/activate.ts	Defines staged-checkout fixes and adds structured activation failure, refund, and recovery outcomes.
Activation and attendee data integrity src/shared/db/attendees/*, src/features/api/payment-processing/committed-entries.ts, test/shared/db/attendees/activate.test.ts, test/lib/processed-payments/locking.test.ts	Validates staged rows without throwing, preserves parent/child booking metadata, uses primary-pinned reads, and standardizes attendee defaults.
Stage storage and administrative guards src/shared/db/checkout-stages.ts, src/features/admin/*, src/ui/templates/admin/attendee-page.tsx, src/locales/en/*, test/lib/server-attendees/*, test/shared/db/checkout-stages.test.ts	Adds nullable stage lookup, shared dependent-row cleanup, overbook-tolerant staging, pending-payment edit/merge guards, and related UI/test coverage.
Provider expiry lifecycle src/shared/limits.ts, src/shared/payments.ts, src/shared/stripe*.ts, src/features/api/webhooks.ts, test/lib/server-payments/cancel.test.ts, test/lib/stripe/core.test.ts	Validates checkout expiry limits, configures Stripe expiration, supports provider session expiry, and discards staged rows on cancellation or expiry events.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Stripe
  participant Webhooks
  participant CheckoutStages
  participant PaymentProcessing
  Stripe->>Webhooks: checkout.session.expired
  Webhooks->>CheckoutStages: discardPendingCheckoutSessions
  CheckoutStages-->>Webhooks: staged rows removed
  Stripe->>PaymentProcessing: checkout completion
  PaymentProcessing->>CheckoutStages: getCheckoutStageOrNull
  PaymentProcessing-->>Stripe: handled or staged payment result

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the PR’s main theme: staged checkout before payment plus broader flow hardening.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/branch-review-comparison-pcwbvd

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9aabe20812

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Actionable comments posted: 8

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/shared/db/attendees/activate.ts (1)

128-155: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Make the stage-active check atomic with the claim
findStageProblem runs before withTransaction, so a concurrent writer can flip a staged row live in that gap and activationStatement will still overwrite it because the UPDATE only matches on identifiers. Move the read into the transaction or add AND quantity = 0 and treat 0 rows affected as stage_active.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/shared/db/attendees/activate.ts` around lines 128 - 155, Make the
stage-active validation in the activation flow atomic with the database claim:
move findStageProblem into the withTransaction callback, or constrain
activationStatement to quantity = 0 and handle an update affecting zero rows as
stage_active. Update the surrounding activate logic while preserving the
existing failure response and transaction behavior.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/features/admin/attendees-merge.ts`:
- Around line 48-50: Move MERGE_PENDING_CHECKOUT_MESSAGE into the appropriate
English locale JSON catalog under a descriptive key, then replace both
references to the constant with t("key") calls using the existing translation
mechanism. Remove the hardcoded constant while preserving the same message
behavior.

In `@src/features/api/payment-processing/store-refund.ts`:
- Around line 282-284: Update the staged validation flow around
getCheckoutStageOrNull and markCheckoutStage so a transient refund failure does
not mark the checkout stage as terminal before the refund outcome is known.
Leave the stage pending, or use an existing refund-pending state that allows
processPaymentSession to retry when result.refunded is false, while preserving
terminal handling for confirmed outcomes.

In `@src/shared/db/checkout-stages.ts`:
- Around line 154-159: Add a deterministic test for the lookup path handling
orphaned staged attendees, using the relevant checkout-stage lookup symbol to
create a staged row whose attendee is then deleted without removing the stage.
Assert the lookup returns null and ensure the test exercises the attendee_exists
=== null branch, including its recovery behavior.
- Around line 179-188: The attendeeIdsWithPendingStage lookup must use the
primary database to avoid replica lag when gating mutations. Replace queryAll
with queryBatchPrimary or the existing primary-only helper while preserving the
current SQL, parameters, empty-input fast path, and Set<number> result.

In `@src/shared/stripe.ts`:
- Around line 460-461: Update the exported expireCheckoutSession wrapper to
declare an explicit return type matching stripeApi.expireCheckoutSession(id),
while preserving its current behavior and delegation.

In `@test/lib/server-attendees/attendee-edit.test.ts`:
- Line 5: The raw listing_attendees quantity query is duplicated across attendee
tests; extract it into a shared `#test-utils` helper named getAttendeeQuantities,
then replace the direct queryAll usage in attendee-edit.test.ts and
merge-post.test.ts with that helper while preserving the existing result shape
and attendee ID parameter.

In `@test/lib/server-attendees/merge-post.test.ts`:
- Around line 154-166: Add a database-state assertion to the “refuses a
mid-payment target” test, using the same queryAll-based verification as the
sibling mid-payment-source test. Confirm the staged attendee row identified by
stage.attendeeId remains unchanged after the merge request, while preserving the
existing redirect and flash assertions.

In `@test/test-utils/db-helpers/processed-payments.ts`:
- Around line 46-50: Add a regression test for the processed payment session
finalization helper that first resolves a session, then calls the finalization
operation again and asserts it throws when rowsAffected is not 1. Reuse the
existing test setup and symbols around finalizeTestPaymentSession, preserving
current successful-finalization coverage.

---

Outside diff comments:
In `@src/shared/db/attendees/activate.ts`:
- Around line 128-155: Make the stage-active validation in the activation flow
atomic with the database claim: move findStageProblem into the withTransaction
callback, or constrain activationStatement to quantity = 0 and handle an update
affecting zero rows as stage_active. Update the surrounding activate logic while
preserving the existing failure response and transaction behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: cf09b603-2955-4fcd-b0fd-7620a9603eed

📥 Commits

Reviewing files that changed from the base of the PR and between 4236e09 and 9aabe20.

📒 Files selected for processing (39)

• TODO.md
• plan.md
• src/features/admin/attendee-form-routes.ts
• src/features/admin/attendee-page.ts
• src/features/admin/attendees-merge.ts
• src/features/api/payment-processing/committed-entries.ts
• src/features/api/payment-processing/create.ts
• src/features/api/payment-processing/index.ts
• src/features/api/payment-processing/recovery-decision.ts
• src/features/api/payment-processing/refunds.ts
• src/features/api/payment-processing/store-refund.ts
• src/features/api/webhooks.ts
• src/locales/en/admin.json
• src/locales/en/attendees.json
• src/shared/db/attendees/activate.ts
• src/shared/db/attendees/atomic-update.ts
• src/shared/db/attendees/create.ts
• src/shared/db/attendees/delete.ts
• src/shared/db/attendees/order-parents.ts
• src/shared/db/attendees/pii.ts
• src/shared/db/checkout-stages.ts
• src/shared/limits.ts
• src/shared/payments.ts
• src/shared/stripe-provider.ts
• src/shared/stripe.ts
• src/ui/templates/admin/attendee-page.tsx
• test/lib/db/attendees/delete-attendee.test.ts
• test/lib/server-attendees/attendee-detail.test.ts
• test/lib/server-attendees/attendee-edit.test.ts
• test/lib/server-attendees/helpers.ts
• test/lib/server-attendees/merge-panel.test.ts
• test/lib/server-attendees/merge-post.test.ts
• test/lib/server-payment-staging.test.ts
• test/lib/server-payments/cancel.test.ts
• test/lib/stripe/core.test.ts
• test/shared/db/attendees/activate.test.ts
• test/shared/db/checkout-stages.test.ts
• test/shared/limits.test.ts
• test/test-utils/db-helpers/processed-payments.ts

[stefan-burke]

Two notes on items without an inline thread:

• CodeRabbit's outside-diff finding (activation stage-active check not atomic with the claim): fixed in 8f6aafb. The activation UPDATE now carries AND quantity = 0 in its own WHERE, so a row flipped live in the gap since the pre-check misses the write; a refused claim re-checks the rows before blaming stock, so a race classifies as a stage conflict (money held for the operator) rather than a refundable capacity failure.
• The failing merge-check: it tries to merge this branch into main, and the conflicts it hits (trusted-and-mismatch.test.ts, listing-overview-stats.test.ts, …) are between the base branch (fix/committed-booking-refunds) and main — files this stacked PR doesn't touch. It will clear once the parent branch (Stage paid bookings until payment succeeds #1764) merges main; resolving them here would drag the parent's conflict resolution into this PR.

---

Generated by Claude Code

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/test-utils/db-helpers/attendees.ts`:
- Around line 108-118: Update getAttendeeQuantities to add an explicit
deterministic ORDER BY clause to the listing_attendees query, using a stable row
identifier so results have consistent ordering when multiple rows exist. Keep
the selected fields and attendeeId filtering unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 3271347e-74d5-4559-ab48-6360d89d91a1

📥 Commits

Reviewing files that changed from the base of the PR and between 9aabe20 and 8f6aafb.

📒 Files selected for processing (16)

• TODO.md
• src/features/admin/attendees-merge.ts
• src/features/api/payment-processing/index.ts
• src/features/api/payment-processing/store-refund.ts
• src/locales/en/admin.json
• src/shared/db/attendees/activate.ts
• src/shared/db/checkout-stages.ts
• src/shared/limits.ts
• src/shared/stripe.ts
• test/lib/processed-payments/locking.test.ts
• test/lib/server-attendees/attendee-edit.test.ts
• test/lib/server-attendees/merge-post.test.ts
• test/lib/server-payment-staging.test.ts
• test/shared/db/checkout-stages.test.ts
• test/shared/limits.test.ts
• test/test-utils/db-helpers/attendees.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8f6aafbfd2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/features/api/payment-processing/store-refund.ts`:
- Around line 225-234: In the refund flow, move markCheckoutStage(session.id,
"failed") to execute after tryRefund and recordPlaceholderRefund complete. Keep
stampStagedPaymentId before the refund attempt, and ensure the stage is marked
failed only after provider and placeholder-refund operations succeed, matching
the failStagedValidation/stagedConflict ordering.

In `@test/lib/server-payments/cancel.test.ts`:
- Around line 60-62: Update the cancel-payment tests around stubExpire and the
try blocks to declare the stub() result with using, relying on Symbol.dispose
for automatic restoration. Remove the manual restore/finally handling and
preserve the existing test behavior and assertions.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2d38c279-7209-4c2e-b432-47e2e131aa19

📥 Commits

Reviewing files that changed from the base of the PR and between 8f6aafb and 5e00658.

📒 Files selected for processing (12)

• src/features/api/payment-processing/committed-entries.ts
• src/features/api/payment-processing/index.ts
• src/features/api/payment-processing/store-refund.ts
• src/shared/db/attendees/atomic-update.ts
• src/shared/db/checkout-stages.ts
• src/shared/db/client.ts
• src/shared/db/listing-prices.ts
• test/lib/server-payment-staging.test.ts
• test/lib/server-payments/cancel.test.ts
• test/test-utils/db-helpers/attendees.ts
• test/test-utils/db-helpers/processed-payments.ts
• test/ui/templates/admin/attendee-detail.test.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5e00658830

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/lib/server-payment-staging.test.ts`:
- Around line 557-565: Replace the manual try/finally disposal in the staged
refund tests with using declarations for the stubSuccessfulRefund result,
matching the existing disposable stub pattern. Apply the same change to checkout
and refund values created by stubCheckout or stubSuccessfulRefund in the
affected tests only when those helpers return stub()-based disposables, and
remove the corresponding restore calls and try/finally wrappers.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0e5b4efe-4b25-4c16-87ac-adc2d9c507df

📥 Commits

Reviewing files that changed from the base of the PR and between 5e00658 and ea9fec6.

📒 Files selected for processing (5)

• src/features/api/payment-processing/index.ts
• src/features/api/payment-processing/store-refund.ts
• src/shared/db/checkout-stages.ts
• test/lib/server-payment-staging.test.ts
• test/lib/server-payments/cancel.test.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9f4c09936b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

tickets/src/features/api/payment-processing/index.ts

Lines 335 to 340 in 3c31ace

	validatedItems,
	pricingIntent,
	pricedOrder,
	preparedTicketToken,
	stage,
	);

Recheck a deleted stage before refunding it

This passes a stage snapshot that may have been deleted by an operator while the payment was being processed. In that race, activateStagedBooking sees no staged lines and reports stage_mismatch; storeRefundedBooking then reloads no stage and creates a refunded placeholder, even though the documented delete path says removing a pending stage lets a late payment book fresh from the signed intent. The result is a valid paid checkout being refunded instead of booked solely because the delete landed after this read.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep staged validation ledger failures retryable

In this new staged-validation path, recordPlaceholderRefund catches ledger write failures and reports them as { posted: false }, but the result is ignored. When a listing closes or is deactivated mid-payment and the provider refund succeeds but the payment/refund ledger round-trip is not stored, this code still writes the note, marks the stage failed, and lets processPaymentSession record a terminal outcome; later deliveries then replay “already processed” and cannot repair the attendee ledger, leaving the operator’s record missing or overstating the refunded cash.

Useful? React with 👍 / 👎.

[stefan-burke]

Resolved in 9d9215c. The closed-listing path now verifies its ledger round-trip through the same shared recordStagedMoneyOrThrow the conflict path uses: a failed write throws before the note and the stage flip, so the stage stays pending and the redelivery re-runs the whole path (the settled refund reads back as refunded, so nothing double-refunds). The regression blocks the payment leg's reference, proves the throw and the pending stage, then repairs the collision and drives the redelivery to the recorded round-trip and a resolved stage.

---

Generated by Claude Code

[chatgpt-codex-connector]

Leave the crash-healing note before resolving

When the ledger preflight finds an orphaned event with a still-pending stage, this call flips the stage to failed before the explanatory note is inserted. If createSystemNote hits a write failure after the update, the next delivery sees no pending stage, returns “already handled,” and never writes the note, so the operator loses the only explanation for the retained/refunded/conflicted staged record.

Useful? React with 👍 / 👎.

[stefan-burke]

Resolved in 9d9215c. The heal reads the pending stage's attendee first (pendingStageAttendeeIdOrNull), writes the note, and only then resolves the stage — so a half-done heal repeats the note on the next delivery instead of losing it forever. A duplicate note beats a permanently missing explanation.

---

Generated by Claude Code

[chatgpt-codex-connector]

Make conflict refunds ledgerable

For a stage_active conflict this stores only a cash payment leg, while the stamped payment reference makes the normal admin refund action available on the now-live row. If the operator follows the note and refunds this charge in-app, recordAttendeeRefund refuses to post the ledger refund because the attendee account has only a credit and no balancing sale, so the provider refund succeeds but the app returns refund_not_recorded and leaves the ledger unreconciled.

Useful? React with 👍 / 👎.

[stefan-burke]

Resolved in 9d9215c. The admin refund guard now recognises pure held cash — covered legs that are all provider payments with no sale — as cleanly reversible, since the reversal returns exactly what we hold and leaves the account at zero. The regression seeds a conflict's held payment and proves the in-app refund posts its refund_cash reversal instead of stranding as refund_not_recorded. Every other shape (still owing, credit mixed with sales) keeps the old fully-paid guard and goes to a manual adjustment.

---

Generated by Claude Code

[stefan-burke]

On Codex's review-body finding ("Recheck a deleted stage before refunding it"): resolved in 9d9215c. When activation finds nothing staged any more — the operator deleted the record between the stage read and the claim, the one sanctioned mid-payment mutation — it now reports the stage gone rather than "changed", and createAttendeeForSession falls through to its own fresh create instead of refunding a bookable payment. The regression hands the production compose chain a genuinely stale snapshot for a deleted record and proves a brand-new attendee books and the payment finalizes against it, honouring the documented delete-mid-payment contract ("a late payment books fresh from the signed order").

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9d9215c86f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Make staged refund ledger writes atomic

When refunded is true, recordPlaceholderRefund can commit the placeholder payment leg and then return { posted: false } if the following account read or refund_cash post fails. Throwing here leaves the stage pending, but after the stale reservation is reclaimed the ledger preflight sees that booking event as orphaned, resolves the stage, and returns “already handled” without ever writing the missing refund leg. A provider-refunded staged checkout can therefore remain recorded as held cash unless the payment and refund legs land atomically or replay can detect the incomplete placeholder refund.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Delay exposing refunds until conflict money is recorded

In the stage_active path, this stamps payment_id before recordStagedMoneyOrThrow has posted the held-payment leg. If that ledger write throws, the stage stays pending for retry, but the attendee now has a payment reference and a quantity-1 line, so the Actions tab's existing refund visibility checks can offer an in-app refund while the payment flow is still unresolved. If the operator refunds in that window, the later retry still records the session as held cash (refunded=false), leaving the ledger out of sync with the provider refund.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 21ed057. Both terminal staged-refund paths (recordHeldStagedMoney and storeRefundedBooking) now post the held-payment leg before stamping the provider payment reference. A failed post throws first, so the still-pending record carries no reference — the Actions tab has no charge to offer an in-app refund against while the money is unrecorded, closing the out-of-sync window you described. Regression test: the blocked-ledger conflict path asserts no payment reference is stamped after the throw (expectNoStampedPayment).

---

Generated by Claude Code

[chatgpt-codex-connector]

Honor failed placeholder ledger posts

In the keep-and-refund path for capacity, price, deleted-listing, or stage_mismatch failures, recordPlaceholderRefund reports ledger write failures as { posted: false }, but this result is ignored. When a staged checkout's provider refund succeeds but the payment/refund ledger round-trip is not stored, this still writes the note, marks the stage failed, and lets processPaymentSession record a terminal failure; later deliveries then replay the failure/resolved stage and cannot repair the retained quantity-0 attendee's missing ledger legs.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 21ed057. storeRefundedBooking now captures recordPlaceholderRefund's {posted} and, on a staged order, throws when the post fails — leaving the stage pending so the provider's next delivery re-posts (the settled refund reads back as refunded, so it never refunds twice). The no-stage path can't retry without minting a duplicate placeholder beside the one it already created, so it still proceeds with the miss logged by postWithoutThrowing (its terminal-outcome design). Regression test: a kept-and-refund placeholder path throws and stays pending on a blocked ledger post, then records the round-trip and resolves on retry.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 37492fb20e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Block no-quantity edits for held conflict cash

When a stage_active conflict reaches this call, it records only a provider payment leg (refunded=false) and deliberately no sale, so the now-editable live row still projects price_paid as 0. The Edit tab's no-quantity guards (isPaymentLockedLine/hasPaidLine) only block sale-backed paid lines, and the refund route later requires hasActiveBookingLine, so in this exact conflict an operator can mark the row no-quantity before refunding and then lose the normal in-app refund path while the provider cash remains held.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 99a13da. The save path now blocks a no-quantity edit while the attendee holds unreturned provider cash. New attendeeHoldsUnreturnedCash is a decryption-free ledger check that the attendee account has a positive balance (cash in, nothing owed against it) — which only a held stage_active payment produces: a fully-paid booking nets to 0, a deposit is negative, a refund nets back to 0. Because that cash has no sale leg, both existing guards (per-line price_paid and the DB hasPaidLine) missed it; this closes the gap with the same "refund this booking's payment first" message. Regression test: an attendee holding a payment leg with no sale is refused the no-quantity mark, and the line is left intact so the in-app refund still reaches.

---

Generated by Claude Code

[chatgpt-codex-connector]

Keep paid pending stages out of unpaid cleanup

When a paid staged checkout hits a retryable path before resolving the stage (for example a closed-listing refund attempt returns false, or a worker crashes and the unresolved reservation is later stale-cleaned), the processed_payments row is removed while the paid stage intentionally stays pending for the next delivery. This NOT EXISTS predicate then makes prunePendingCheckoutStages treat that paid-but-unresolved record as abandoned and delete its attendee after the retention window, so later webhook retries have no staged record to note, reconcile, or keep for the operator even though real money was captured.

Useful? React with 👍 / 👎.

[stefan-burke]

Accurate finding — and after weighing it with the owner, this one is a deliberate accepted edge, not a code change (documented in TODO.md, fa8b15d).

The reasoning: the money is never lost — it stays captured at the provider throughout, so the prune only removes our staged record, never the funds. And the failure that gets a stage into this state (a refund returning false, a ledger write failing, a crash) fires logError → ntfy + the admin activity log + Sentry on every delivery, and the provider re-delivers across its ~3-day retry window. So the operator is alerted repeatedly during the window and reconciles (manual refund / fix at the provider) well before the 7-day prune. Reacting to the failure is the fix, which moots the prune.

If it ever needs a hard fix, the TODO records the two paths: a durable "payment captured" mark on checkout_stages (stamped on the first paid delivery) skipped by prunePendingCheckoutStages, or recording the captured cash as a held payment leg on deferral so the record is kept and operator-actionable (the held-cash model, now guarded). The prune's NOT EXISTS processed_payments guard is unchanged.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 52937b8b3a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore staged ghost rows after listing deletes

Fresh evidence for the staged-row drift case: listingDeleteError is only a preflight read before performListingDelete, so a checkout can insert its pending stage after the guard passes and then have deleteListing remove its listing_attendees rows. In the deleted-listing refund path this branch reuses that now-empty staged attendee and ignores the datelessGhostBookings passed in, so the refund and note attach to a record with no booking rows and the operator loses the order the customer paid for; restore the signed ghost rows or make the delete/stage race impossible before resolving the stage.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 5818fbb by closing the race at its source rather than repairing after it. deleteListing no longer cascades the listing_attendees rows of an attendee whose checkout is still pending, so a delete that slips past the preflight guard leaves the quantity-0 order intact — storeRefundedBooking then reuses a staged record that still has its rows, and the empty-staged-attendee state is now unreachable (so the ignored datelessGhostBookings no longer matter). A resolved (booked/failed) stage's rows are cascaded as before.

Regression test in test/shared/db/listings/delete.test.ts ("keeps a pending checkout's rows, but cascades a resolved one's") fails before the fix — the pending rows were deleted — and passes after.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d73c4f05e9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep deleted staged listings visible to operators

Fresh evidence for the earlier staged-row drift case: the preserved row still cannot render because getRenderListings builds the attendee editor/booking table from getAllListings() and only includes active or inactive rows that still exist in listings, while this batch deletes the listing row later. When a stage is inserted after listingDeleteError but before this delete, the payment refund keeps a listing_attendees row whose listing no longer resolves, so attendeeBookingsFromLines drops it and the operator still cannot see what the customer bought; either keep a renderable ghost listing/line or make the delete race impossible.

Useful? React with 👍 / 👎.

[stefan-burke]

The data loss is fixed — 5818fbb preserves the pending-staged rows, so the refund, the ledger money round-trip, and the system note all attach to a record that still holds the order. What remains is the bookings table dropping a line whose listing was deleted (attendeeBookingsFromLines resolves each line's listing from getAllListings() and skips a missing one). That's a pre-existing render limitation shared with the no-stage datelessGhostBookings refund path — both create rows for a deleted listing — and the operator still sees the situation via the system note and the payment/ledger panel.

Closing the race can't remove deleted-listing ghosts anyway: when a listing is deleted mid-payment the no-stage path creates one regardless, so the durable fix is a renderable "deleted listing" placeholder line (read-only — a deleted listing can't be re-booked). That's an operator-UX call I've deliberately folded into the admin-lifecycle work (review item #8) so the placeholder is designed once across every deleted/pending case rather than piecemeal. Recorded in TODO.md (756503b).

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 880ac8eed0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Redirect pending logistics saves to a visible tab

When a Logistics POST races with a newly staged checkout, this redirects back to the Logistics tab, but attendee-page.ts now hides that tab while pendingCheckout is true and the hidden tab URL 404s. In that scenario the operator lands on a missing page instead of seeing the pending-checkout flash/banner; the Edit handler already redirects to the overview for this exact reason, so this guard should target the always-visible attendee overview too.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 4c8aeff. The Logistics mid-payment refusal now redirects to the always-visible overview (attendeePage.path(id, "")), exactly like the Edit handler — the flash carries the "mid-payment" refusal and the banner explains the locked state. Regression test updated: the redirect lands on the overview, never the hidden /logistics URL.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

tickets/src/features/admin/attendee-page.ts

Line 257 in 03c0564

visible: (_entity, session) => session.adminLevel === "owner",

Hide ledger writes while checkout is pending

This leaves the owner-only Ledger tab visible for a pending staged checkout even though that tab embeds AccountStatementActions, which offers owner-entered ledger entries for attendee accounts. In the inspected attendee page flow, an owner can add a manual attendee charge/payment while the customer is still paying; when the provider payment later activates, the signed checkout posts its own sale/payment legs but the manual entry survives, so a fully paid ticket can unexpectedly show a balance or credit despite the mid-payment freeze applied to the Edit/Logistics/Actions tabs. Gate this tab's write controls, or the tab itself, on the same notMidPayment condition.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep deleted rows out of the edit form

When a listing is deleted during a pending checkout, this now builds an edit-form line with listing: null, but the Edit tab still renders every line through ListingRow, which immediately dereferences line.listing! and reads listing.listing_type. After the payment path resolves the stage, pendingCheckout is false and the operator can open the Edit tab for the kept refund record, causing the attendee page to throw instead of letting them view or repair the record; the null placeholder should be limited to read-only booking summaries or the editor must skip/render it safely.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in ecb5f81. The editor now renders a listing: null line as a locked row instead of throwing: a "Deleted listing" placeholder, the line's hidden identity fields, and a hidden no-quantity tick — no editable controls. Locked (not skipped) because the save deletes any row its form omits, so filtering the line out would silently drop the kept record's booking on the next save. The model retains the row (isNoQuantityLine now keeps a stored row whose listing is gone), the desired line re-states the row's own stored date range (so the atomic edit sees an unchanged preserve), and validation refuses a hand-crafted submission that un-ticks the lock. Regression tests: the edit form renders 200 with the locked row, an unrelated save keeps the quantity-0 row, the un-lock attempt 400s with the row intact, plus unit tests on retention/range/validation — all fail before the fix.

---

Generated by Claude Code

[stefan-burke]

On Codex's review-body finding ("Hide ledger writes while checkout is pending", attendee-page.ts:257): fixed in ecb5f81. The Ledger tab's visible is now ANDed with the same notMidPayment gate as the Edit/Logistics/Actions tabs, so it hides while a checkout is pending and its URL 404s (visible IS the authorization on the entity page). That closes the window where an owner could post a manual charge/payment mid-payment and have it combine with activation's own legs into a surprise balance — and a pending stage has zero ledger legs, so the tab had nothing to show anyway. The hides-write-tabs regression test now also asserts the /ledger link is absent and the URL 404s while pending, and returns once the stage resolves; it fails before the fix.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ecb5f81154

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Block listing deletes while conflict cash is held

When a staged checkout reaches the stage_active path, its stage is marked failed after recording a provider payment leg with no sale, so listingHasPendingCheckout no longer matches. The listing delete flow then falls through here and deleteListing removes that attendee's booking row because it only preserves state = 'pending' rows; after that canRefundAttendee hides the refund action because there is no active booking line, leaving the held charge without the in-app refund path the conflict note tells the operator to use. Please also reject deleting a listing while any attendee on it holds unreturned cash.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in db71893. listingDeleteError now also refuses the delete while any attendee booked on the listing holds unreturned conflict cash — new listingHoldsUnreturnedCash reads the listing's attendee ids and runs them through the same primary-pinned attendeeIdsHoldingUnreturnedCash batch guard the no-quantity/delete/merge gates use, so every write gate that consults held cash stays one mechanism. The refusal message tells the operator to refund first. Regression test: a listing whose attendee carries a held payment (no sale) is refused deletion and survives, keeping the booking line the in-app refund needs — fails before the fix.

---

Generated by Claude Code

[chatgpt-codex-connector]

Block standalone ledger writes during checkout

This hides the attendee Ledger tab while a stage is pending, but the standalone owner ledger routes are still writable: checked src/features/admin/ledger/entries.ts, and POST /admin/ledger/:type/:ref/add loads an attendee account and calls postManualLedgerEntry without checking hasPendingCheckout. An owner with /admin/ledger/attendee/<id>/add can therefore post a manual payment or charge while the provider checkout is still in flight; when activation later posts the checkout's own sale/payment legs, the account can show a surprise balance. Please apply the same pending-checkout guard to the standalone attendee ledger write route.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in db71893. POST /admin/ledger/:type/:ref/add now refuses an attendee-account entry while that attendee's checkout is pending, with the same "mid-payment" refusal flash the other write guards use. The guard lives in the write handler itself — the one route behind both the (already hidden) Ledger tab's form and the standalone statement page — so no surface can post a manual leg that would combine with activation's own sale/payment legs into a surprise balance. Regression test: a manual payment against a pending staged attendee is refused and no transfer is written — fails before the fix.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: db718939a7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Hide actions when the home listing is gone

When a checkout races with listing deletion, this PR now keeps the attendee row with a listing_attendees.listing_id whose listings row has been deleted. After the stage resolves, pendingCheckout is false, so the Actions tab is shown here; however the attendee-scoped action routes still load the home listing with getListingWithCount(attendee.listing_id) and return null when it is missing (src/features/admin/attendees-route-helpers.ts:85-87). That leaves delete/resend/refund action links visible on the retained deleted-listing record even though those targets 404, so either gate the actions on a renderable home listing or make the action loader handle deleted-listing records.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 0ffd541 with the first option — gate the actions on a renderable home listing. LoadedAttendee gains homeListingExists (loaded via getListingWithCount(attendee.listing_id) !== null, the exact condition loadAttendeeWithHomeListing enforces), and the Actions tab's visible is now notMidPayment(entity) && entity.homeListingExists. So a resolved deleted-listing record no longer renders delete/resend/send-text links that 404 (refund was already gated on canRefund, which is false for a quantity-0 record) — the tab hides just as it does while a checkout is pending. Making the action loader fully handle deleted-listing records (so delete/refund actually work on them) is the larger "design the deleted-listing operator UX once" item still tracked in TODO.md; this closes the dead-link half now. Regression test: after the stage resolves on a raced-delete record, the /actions link is absent and GET …/actions 404s while the Edit tab is back — fails before the fix.

---

Generated by Claude Code

[chatgpt-codex-connector]

Only block no-quantity saves that remove the refund path

Fresh evidence: this new held-cash guard rejects any submitted form that contains a no-quantity line, not just edits that remove the last line the in-app refund can use. A stage_active record can have one staged row flipped live while another signed row is still quantity 0; when the live row is the attendee's home line, the refund route still has an active booking, but any later save submits the remaining no-quantity row and is refused here. That blocks the operator from fixing the quantities the conflict note asks them to check unless they refund first, even when the edit would leave the refund path intact.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 0ffd541. The guard no longer fires on "any no-quantity line present" — it now blocks only a save that would leave the home listing with no active booking line while held cash exists (keepsHomeRefundLine = parsed.lines.some(line => line.listingId === attendee.listing_id && (line.quantity ?? 0) >= 1)). The refund route is home-scoped (canRefundAttendee → hasActiveBookingLine(id, attendee.listing_id)), so a save that keeps an active home line leaves the refund path intact and is now allowed — the operator can fix the other quantities the conflict note asks about. As a bonus it also catches a case the old some(isNoQuantityLine) check missed: removing the home line by zeroing it un-ticked (not marking it no-quantity) also strands the cash, and is now blocked. The paid-line and held-cash refusals share one guard/message now. Regression tests: an edit that keeps the home line active while marking another line no-quantity now saves (fails before the fix), and marking the home line no-quantity while another stays active is still blocked.

---

Generated by Claude Code

[chatgpt-codex-connector]

Keep failed staged refunds retryable

When tryRefund returns false for a staged stored-refund path, recordPlaceholderRefund(..., refunded=false) still posts the provider payment leg, and this line then marks the stage failed. processPaymentSession releases the reservation for refunded === false so the next delivery can retry the refund, but that retry now hits the ledger preflight: the payment leg makes the session look already handled, the stage is no longer pending, and tryRefund is never called again. Leave the staged record retryable until the provider refund succeeds, or avoid writing the terminal held-money leg before resolving the failed refund.

Useful? React with 👍 / 👎.

[stefan-burke]

Fixed in 0ffd541, taking the second option you suggested — don't write the terminal held-money leg before the refund settles. storeRefundedBooking now splits by whether the order was staged: when there IS a stage and tryRefund returned false, it returns early with refunded: false and posts NO ledger legs, leaving the stage pending. That releases the reservation and returns 503, so the provider redelivers; the retry finds the ledger unrecorded (bookingLedgerDisposition → unrecorded) and the stage still pending, so it re-runs the whole path and re-attempts tryRefund until it settles — the same retryable design as failStagedValidation. The no-stage path is unchanged and stays terminal (a retry there would mint a duplicate placeholder beside the one already created). Regression test: a staged capacity-loss order whose refund fails stays pending with no legs and no stamped reference, then resolves with the full payment+refund_cash round-trip once the refund succeeds on retry — fails before the fix (which resolved the stage and posted the payment leg).

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 31a4910e64

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Refresh staged booking dates on activation

If a daily listing’s duration changes while a staged checkout is pending, activation checks capacity using the newly recomputed bookings span but this update only flips the old staged rows from quantity 0 to the paid quantity. The row’s existing start_at/end_at from checkout creation are left in place, and the match above only keys on start_at, so shortening a listing mid-payment can activate an old longer row after checking capacity only for the new shorter span. Include the expected end date in the stage match or rewrite the date fields together with the quantity.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Mark the stage refunding before validation refunds

Fresh evidence: the known-listing failure refund still happens inside validateAllItems before this staged handoff can call beginCheckoutStageRefund. If a closed/deactivated staged checkout is refunded and the worker crashes before reaching this line, the stage remains pending with no ledger record; after the stale reservation is reclaimed, a redelivery can re-run validation and, if the listing has reopened, activate a live ticket for money that has already been returned. Move the provider refund behind the stage's refunding transition or return a refund-needed result that this staged path performs after that transition.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1a5eeab0c9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Include refunding stages in checkout status

When a staged refund has begun (beginCheckoutStageRefund sets the stage to refunding after a closed/deactivated mid-payment checkout), all mutation guards treat it as open via hasPendingCheckout, but this projection returns pending_checkout = 0. The attendees/dashboard tables and CSV therefore show the quantity-0 row as ordinary “No quantity” or omit the checkout-pending column while the detail page is still locked, hiding a payment/refund still in flight; use the shared open-state predicate here too.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Add a bounded path for refunding stages

If a staged refund enters refunding and refund attempts keep failing until provider redeliveries stop, the row is no longer eligible for the pending-stage purge and this resolved-stage purge only removes booked/failed. Because admin mutation guards include refunding as an open stage, that attendee remains locked and unprunable indefinitely with no scheduled reconciliation path; old refunding rows need a terminal/operator-visible recovery path instead of being omitted from cleanup.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Check registration cutoff before creating checkout

This new pre-provider refusal only asks the capacity checker, which enforces active listings and space but not registration_closes_at. If registration closes after the form context is prepared (or on the direct QR checkout path) but before this call, available can still be true and the customer reaches the card page for an order that validateAllItems will immediately refund after payment; include the same registration-closed check here so closed orders are refused before money moves.

Useful? React with 👍 / 👎.

[stefan-burke]

Closing — superseded by #1853 (split/staged-checkout-runtime), which is now the canonical staged-checkout PR.

When this PR was filed it carried two layers at once:

1. The staged-checkout runtime (write bookings at quantity zero before payment, activate atomically on payment success, shared close/refund across Stripe/Square/SumUp).
2. An integrity layer on top: backups that survive in-flight payments, payment safety across site upgrades/moves, mid-payment record locking, deleted-listing survival, stray Stripe webhook endpoint cleanup.

We've decided against (2). The integrity layer added real complexity for cases we don't need to support — the running version doesn't need to preserve open payments across backups or site upgrades. Removing that defensive scaffolding rather than maintaining it.

That leaves the runtime as the thing to ship, and it has been split off to #1853. That branch is actively passing precommit, has absorbed the latest main, and addresses Codex review. It carries the same deferred-architecture design notes (STAGED_TODOS.md, STAGED_DESIGN.md, SCHEDULED_DESIGN.md, COMPLETION_DESIGN.md) as documentation only.

One non-integrity piece unique to this PR is worth a follow-up if it turns out to still be needed:

• src/shared/stripe-webhook-reconcile.ts removed any stray webhook endpoints already pointing at this site on Stripe setup (left by a lost setup or database restore, which would fail signature checks forever). If Finish and recover paid checkouts safely #1853 still creates stray endpoints in those scenarios, re-add this as a small standalone fix.

The 170 unique files on this branch remain recoverable in git history. The branch itself is intentionally left in place (not deleted) for the same reason.