Repository navigation
Harden launch readiness: signup credits, webhooks, env, payment verification - #29
Conversation
…ication Addresses the remediation plan in #28 (findings in #27). Signup credits (the main user-facing bug): - Add CLERK_WEBHOOK_SIGNING_SECRET to the env contract so a prod deploy missing it fails the build instead of silently 400-ing every Clerk webhook. - Clerk webhook now returns 200 for ignored event types (was falling through to a 500, which degrades endpoint delivery health) and logs via console.error. - Add ensureSignupGrant(): a self-healing fallback that grants the signup bonus on first balance load if the webhook never landed it. Idempotent via the unique source_id constraint, deterministic signup:<userId> id, and treating Postgres 23505 as success. Both grant paths now share SIGNUP_BONUS_CREDITS and write identical rows. Payments: - Append ?session_id={CHECKOUT_SESSION_ID} to the Stripe success_url. - Rewrite /payment/success as a server component that verifies the session with Stripe (plus an ownership check) instead of unconditionally claiming success; shows a processing state while the webhook lands and redirects invalid/foreign sessions to /billing. Observability: - Log both previously-silent Stripe webhook catch blocks with event id/type. - Gate the tRPC per-call timing log to development. Housekeeping: - Remove duplicate cdn.animeroom.space image remote pattern. - Gitignore the standalone launch-readiness-field-guide/ repo. Verified: pnpm verify:launch passes (typecheck, lint, format, 33 tests, build). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 56 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Free Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe changes add idempotent signup-credit initialization, strengthen Clerk and Stripe webhook handling, validate payment sessions before rendering success states, require the Clerk webhook secret in environment validation, and adjust runtime logging and repository configuration. ChangesPayments and signup credits
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant paymentRouter.startPayment
participant Stripe
participant PaymentSuccessPage
participant auth
Client->>paymentRouter.startPayment: Start checkout
paymentRouter.startPayment->>Stripe: Create checkout session with success_url
Stripe-->>Client: Redirect with session_id
Client->>PaymentSuccessPage: Request success page
PaymentSuccessPage->>auth: Authenticate user
PaymentSuccessPage->>Stripe: Retrieve and verify session
Stripe-->>PaymentSuccessPage: Return payment status and ownership metadata
PaymentSuccessPage-->>Client: Render payment state or redirect to billing
Poem
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
The env contract now requires CLERK_WEBHOOK_SIGNING_SECRET, so the CI verify job must supply it like the other secrets or env validation fails fast during lint/build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Implements the remediation plan in #28 (findings in #27). All changes verified with
pnpm verify:launch(typecheck, lint, format, 33 tests, production build).Signup credits (the main user-facing bug)
CLERK_WEBHOOK_SIGNING_SECRETadded to the env contract; a prod deploy missing it now fails the build instead of silently 400-ing every Clerk webhook.200for ignored event types (was falling through to a 500) and logs viaconsole.error.ensureSignupGrant()self-healing fallback: grants the signup bonus on first balance load if the webhook never landed it. Idempotent via the uniquesource_idconstraint + deterministicsignup:<userId>id, treating Postgres23505as success. Both paths shareSIGNUP_BONUS_CREDITS.Payments
?session_id={CHECKOUT_SESSION_ID}appended tosuccess_url;/payment/successrewritten to verify the session with Stripe (+ ownership check), show a processing state while the webhook lands, and redirect invalid/foreign sessions to/billing.Observability
catchblocks now log withevent.id/event.type.Housekeeping
.envonly, not in this diff) Inngest key typo fixed.cdn.animeroom.spaceimage pattern.launch-readiness-field-guide/repo..envkeys are unused).Still requires dashboards (out of scope for this PR)
CLERK_WEBHOOK_SIGNING_SECRETwith the prod Clerk secret; check for theINNGEST_SIGNINtypo.user.createdwebhook delivery log.DATABASE_URL(pooler reports "tenant not found" locally).🤖 Generated with Claude Code