Preview deployment for your docs. Learn more about Mintlify Previews.

💡 Tip: Enable Workflows to automatically generate PRs for you.

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
worldmonitor	Ready	Preview, Comment	Jun 27, 2026 8:21am

Greptile Summary

This PR extends the checkout dedup guard to also block new checkouts when a recent same-tier pending 3DS/SCA payment exists, addressing a gap that allowed customers to stack duplicate "Requires customer action" payments. The block surfaces as a confirm-to-proceed dialog (soft friction with a bypass), and the plan key is threaded through checkout-session metadata so the webhook can persist tier-group information on the paymentEvents row.

• U1 (data plumbing): wm_plan_key added to Dodo checkout-session metadata; planKey persisted on new paymentEvents rows; schema migration is additive and backward-compatible.
• U2 (guard): getBlockingPendingPayment (15-min staleness window, tier-group scoped, fails open) enforced after the subscription guard in both createCheckout and internalCreateCheckout; bypassPendingGuard flag threads through client → edge → relay → Convex.
• U3/U4 (taxonomy + dialog): payment_in_progress error code added to the client taxonomy; confirmation dialogs implemented for both the dashboard (service-layer, DOM API) and /pro (inline, separate build).

Confidence Score: 4/5

The core dedup logic is correct — tier-group scoping, fail-open, bypass, and test coverage are all solid. The main risk is edge-case messaging: stale processing rows can show a "Payment in progress" dialog after a payment has already succeeded, though in practice the subscription guard fires first and the bypass dialog always allows recovery.

The guard, metadata bridge, schema change, and dialog wiring are all correct and well-tested. The only substantive concern is that getBlockingPendingPayment never cross-checks whether a terminal-status row (succeeded/failed) already exists for the same dodoPaymentId, which can cause misleading dialog messaging in a narrow timing window. The accessibility gaps in the pro-test dialog and the missing pendingPayment field on CheckoutErrorBody are straightforward clean-ups.

convex/payments/billing.ts — the guard query and the stale-row edge case; pro-test/src/services/checkout.ts — accessibility attributes on the inline dialog.

Important Files Changed

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant U as User
    participant C as Client (checkout.ts)
    participant E as Edge (/api/create-checkout)
    participant R as Relay (convex/http.ts)
    participant A as internalCreateCheckout
    participant SG as Subscription Guard
    participant PG as Pending Guard (NEW)
    participant D as Dodo Payments

    U->>C: startCheckout(productId)
    C->>E: POST /api/create-checkout
    E->>R: relay to Convex
    R->>A: internalCreateCheckout(userId, productId)
    A->>SG: getCheckoutBlockingSubscription
    alt Active subscription in same tier
        SG-->>A: blocking sub
        A-->>C: 409 ACTIVE_SUBSCRIPTION_EXISTS
        C->>U: showDuplicateSubscriptionDialog
    else No active subscription
        SG-->>A: null
        A->>PG: getBlockingPendingPayment
        alt Recent pending 3DS, same tier, no bypass
            PG-->>A: blocking pending payment
            A-->>C: 409 PAYMENT_IN_PROGRESS
            C->>U: showCheckoutPendingDialog
            U->>C: onConfirm
            C->>E: "POST bypassPendingGuard=true"
            Note over E,D: Guard skipped
        else No blocking pending payment
            PG-->>A: null
            A->>D: create session + wm_plan_key
            D-->>C: checkout_url
            C->>U: navigate to Dodo hosted checkout
        end
    end

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant U as User
    participant C as Client (checkout.ts)
    participant E as Edge (/api/create-checkout)
    participant R as Relay (convex/http.ts)
    participant A as internalCreateCheckout
    participant SG as Subscription Guard
    participant PG as Pending Guard (NEW)
    participant D as Dodo Payments

    U->>C: startCheckout(productId)
    C->>E: POST /api/create-checkout
    E->>R: relay to Convex
    R->>A: internalCreateCheckout(userId, productId)
    A->>SG: getCheckoutBlockingSubscription
    alt Active subscription in same tier
        SG-->>A: blocking sub
        A-->>C: 409 ACTIVE_SUBSCRIPTION_EXISTS
        C->>U: showDuplicateSubscriptionDialog
    else No active subscription
        SG-->>A: null
        A->>PG: getBlockingPendingPayment
        alt Recent pending 3DS, same tier, no bypass
            PG-->>A: blocking pending payment
            A-->>C: 409 PAYMENT_IN_PROGRESS
            C->>U: showCheckoutPendingDialog
            U->>C: onConfirm
            C->>E: "POST bypassPendingGuard=true"
            Note over E,D: Guard skipped
        else No blocking pending payment
            PG-->>A: null
            A->>D: create session + wm_plan_key
            D-->>C: checkout_url
            C->>U: navigate to Dodo hosted checkout
        end
    end

_{Reviews (1): Last reviewed commit: "build(pro): rebuild public/pro for the p..." | Re-trigger Greptile}

Thanks for the adversarial pass — the BLOCKING finding was a real bug. Addressed in 7d6ba08:

✅ Finding 1 (BLOCKING) — stale pending rows from terminal payments — fixed

You were exactly right: paymentEvents is append-only, so processing → failed/succeeded leaves the pending row behind, and the guard blocked the failure-retry path for the whole window. getBlockingPendingPayment now dedups by dodoPaymentId: it builds the set of payment ids that have any terminal (non-pending) charge row and excludes them, so a payment only blocks when it has no terminal row. New tests cover the append-only coexistence your review pointed at:

• processing + failed (same dodoPaymentId) → not blocked
• processing + succeeded (same dodoPaymentId) → not blocked
• genuinely-pending alongside an unrelated terminal payment → still blocked

✅ Finding 2 (SUGGESTION) — unbounded .collect() / fail-closed — fixed

Added a by_userId_occurredAt index and the guard now reads a time-bounded slice (occurredAt > windowStart) instead of the user's whole history. A terminal row always post-dates its own pending row, so it's still in-window and the dedup logic stays correct — and the read can no longer blow the transaction limit and reject the checkout (fail-open preserved).

✅ Finding 3 (SUGGESTION) — dialog overpromises — fixed

Dropped the "will not charge you twice for the same plan" guarantee on both surfaces; replaced with honest recourse: "if it does and you're charged twice, contact support and we'll refund the duplicate."

Finding 4 (NITPICK) — edge 409 default || 'ACTIVE_SUBSCRIPTION_EXISTS' — acknowledged, left as-is

Confirmed unreachable: the relay always sets error: result.code (convex/http.ts:1298), and both blocked shapes always carry code. Changing the default to a neutral value would route the impossible no-error case to invalid_product instead — no real improvement, so I left the historical default rather than churn it. Happy to add a one-line // relay always sets code comment if you'd prefer.

Finding 5 (NITPICK) — dialog test reimplements the unit — acknowledged

Agreed it stubs the dialog and drives a harness rather than the real startCheckout end-to-end (matches the repo's existing checkout-overlay-lifecycle.test.mts pattern, which stubs the duplicate dialog the same way). The contract — re-invoke with bypassPendingGuard, navigate on confirm, inert on cancel — is locked; left as-is for consistency.

Convex suite green (479), tsc clean (src + convex + pro-test), public/pro/ rebuilt.

Thanks @greptileai — your pass landed on 2c39f3ca8, the commit just before the review fixes, so two of these were already addressed; the third + the a11y note are now done in 518a2b3.

✅ #1 — unbounded .collect() before the time-window filter — already fixed in 7d6ba08

The guard now reads a bounded slice via a new by_userId_occurredAt index with q.eq("userId", …).gt("occurredAt", windowStart) (convex/payments/billing.ts), instead of collecting the whole history and filtering in JS. This also makes the read fail-open rather than risking a transaction-limit throw.

✅ #2 — stale processing row blocks after the payment succeeded/failed — already fixed in 7d6ba08

Exactly the append-only hazard. getBlockingPendingPayment now dedups by dodoPaymentId: it builds the set of payment ids that have any terminal (non-pending) charge row in the window and excludes them, so a payment only blocks when it has no terminal row. Covered by three new tests (processing+failed, processing+succeeded, and genuinely-pending-alongside-unrelated-terminal).

✅ #3 — CheckoutErrorBody doesn't declare pendingPayment — fixed in 518a2b3

Declared both 409 block shapes on the interface — subscription? and pendingPayment? — and dropped the type-intersection casts at both call sites in src/services/checkout.ts (removed the now-unused named import too). The interface now describes the real 409 body, discriminated by error.

✅ a11y — /pro pending dialog missing aria-labelledby — fixed in 518a2b3

Added aria-labelledby + an id on the heading to the /pro showProPendingPaymentDialog, matching the dashboard checkout-pending-dialog.ts.

tsc clean (src + convex + pro-test), convex suite green (479), public/pro/ rebuilt.

All four items resolved — thanks for the detailed rundown. The append-only dedup via dodoPaymentId terminal-row exclusion is exactly the right approach for #2, and the CheckoutErrorBody interface cleanup is cleaner than the intersection casts.

This looks good to merge from my end.

Code review pass complete. No actionable findings from the remote PR-head review.\n\nChecked the pending-payment guard wiring, wm_plan_key metadata bridge, PAYMENT_IN_PROGRESS 409 propagation through Convex relay / Vercel edge / client taxonomy, dashboard and /pro confirm-to-bypass dialogs, and the prior Greptile ARIA feedback. The ARIA comments appear addressed in the current PR head.\n\nValidation note: git diff --check passed. I did not check out the PR branch, so I could not run the PR-head test files from this local main worktree.