feat(wave6): Inventory + Stripe Payment Processing

[TechHypeXP]

Summary

Completed Wave 6: Stripe checkout integration, atomic inventory management, and order tracking.

Features Implemented

• Stripe Checkout: Convert cart → Stripe session, handle payments securely
• Inventory Management: Real-time stock levels, atomic decrements via RPC, restore on failure
• Webhook Handler: Process checkout.session.completed, payment_intent.payment_failed
• Order History: List user orders, order detail view with items and status
• Payment Status: pending → succeeded → processing / failed
• Redis Cache: Inventory cache (5m TTL) for performance
• Migration 015: Orders table extended with stripe_session_id, payment_status, subtotal/tax/shipping

API Endpoints

• POST /api/checkout - Create Stripe session
• POST /api/webhooks/stripe - Webhook handler
• GET /api/orders - List orders (paginated, RLS-scoped)
• GET /api/orders/[id] - Order detail

Architecture

✅ Atomic RPC functions (Law #1): decrement_product_inventory, increment_product_inventory
✅ Request-scoped Supabase clients (Law #2)
✅ Stripe idempotency keys (prevent duplicate charges)
✅ Full audit logging (orders_audit table)

Files Changed

• 12 new files (~1,154 LOC)
• 1 migration (015_inventory_and_payments.sql)

Sequential Dependency

Prerequisite: Wave 5 (Product Catalog) — PR #23
Blocks: Wave 7 (Admin Dashboard)

Testing

• Checkout flow with Stripe test card (4242 4242 4242 4242)
• Inventory decrements after successful payment
• Payment failure restores inventory
• Order history displays correctly
• Webhook replay is idempotent

🤖 Generated with Claude Code

---

Summary by cubic

Adds Stripe Checkout with idempotent webhooks and atomic inventory (no oversells), plus user-scoped orders APIs and a dashboard. Retries now reuse the same pending order, and Stripe remains optional so builds work without keys.

• New Features

  • Retry-safe checkout: idempotency key from user+cart; reuse existing pending orders; stamp user_id/order_id on the PaymentIntent.
  • Idempotent webhooks: dedupe by Stripe event.id; handle payment_intent.created, checkout.session.completed/expired, and payment_intent.payment_failed with status guards to prevent double decrements/restores.
  • Hardened inventory/auth: check RPC success to block oversells; invalidate @upstash/redis cache on changes; API routes restore Supabase session from cookies; Stripe client/webhook are lazy and return 503 when unconfigured.

• Migration

  • Apply 015_inventory_and_payments.sql, 016_orders_user_scoped_writes.sql, 017_orders_checkout_idempotency.sql (adds orders.checkout_idempotency_key with a unique partial index).
  • Set envs to enable payments (optional): STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN, NEXT_PUBLIC_APP_URL. Install uuid. Configure Stripe webhook to /api/webhooks/stripe.

^{Written for commit 189bf9e. Summary will update on new commits.}

Summary by CodeRabbit

• New Features
  • Added a “My Orders” dashboard with order list/details, status/payment indicators, totals, and item breakdown.
  • Implemented Stripe one-time checkout with retry-safe idempotency and webhook-driven order updates.
  • Added inventory availability checks plus automatic inventory decrement and restoration on payment failures/expirations.
  • Introduced order audit history and payment/inventory tracking for better transparency.
• Bug Fixes
  • Tightened access controls so customers can view their own orders, create orders only for their account, and delete only their own pending orders.

[sourcery-ai]

Sorry @TechHypeXP, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
hex-diva	Ready	Preview, Comment	Jul 21, 2026 8:26am

[netlify]

✅ Deploy Preview for hex-diva ready!

Name	Link
🔨 Latest commit	189bf9e
🔍 Latest deploy log	https://app.netlify.com/projects/hex-diva/deploys/6a5f2ce1ee854b0008a2f755
😎 Deploy Preview	https://deploy-preview-24--hex-diva.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[coderabbitai]

Walkthrough

Adds inventory and payment schema support, Redis-backed inventory operations, Stripe checkout and webhook flows, authenticated order APIs, and a dashboard page for viewing orders and details.

Changes

Inventory and payment flow

Layer / File(s)	Summary
Schema and shared contracts migrations/015_inventory_and_payments.sql, migrations/016_orders_user_scoped_writes.sql, migrations/017_orders_checkout_idempotency.sql, src/types/database.types.ts, package.json	Adds inventory, payment, audit, idempotency, and user-scoped order database contracts, migrations, RPC functions, policies, indexes, and UUID support.
Inventory caching and atomic updates src/lib/inventory/*	Adds Redis-backed inventory reads, availability checks, atomic decrement/restore operations, and cache invalidation.
Stripe client and checkout session src/lib/stripe/*	Adds Stripe types, lazy client initialization, checkout-session creation, metadata, invoice creation, and idempotency handling.
Authenticated checkout creation src/app/api/checkout/route.ts	Authenticates users, validates carts and inventory, creates or reuses orders and items, starts Stripe Checkout, and records an audit event.
Stripe payment state transitions src/app/api/webhooks/stripe/route.ts	Verifies Stripe webhooks, updates order payment states, adjusts inventory, handles failures and expiration, and records audit entries.
Order retrieval and dashboard presentation src/app/api/orders/[id]/route.ts, src/app/(dashboard)/orders/page.tsx	Adds authenticated order-detail retrieval and a dashboard list with selectable order details, statuses, items, and totals.
Project configuration updates .eslintrc.json, next-env.d.ts	Updates ESLint environment/parser settings, lint rules, and generated route typings.

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

Sequence Diagram(s)

sequenceDiagram
  participant Customer
  participant CheckoutAPI
  participant InventoryManager
  participant Supabase
  participant Stripe
  participant WebhookAPI
  Customer->>CheckoutAPI: Submit checkout
  CheckoutAPI->>Supabase: Authenticate and create or reuse order
  CheckoutAPI->>InventoryManager: Check inventory
  CheckoutAPI->>Stripe: Create checkout session
  Stripe-->>Customer: Checkout session
  Stripe->>WebhookAPI: Send payment event
  WebhookAPI->>InventoryManager: Decrement or restore inventory
  WebhookAPI->>Supabase: Update order and write audit record

Loading

Possibly related PRs

• Hex-Tech-Lab/hex-diva#23: Directly overlaps the inventory, checkout, orders, and Stripe implementation surface.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 17.65% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
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 accurately captures the main change: Wave 6 inventory and Stripe payment processing.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch wave-6-inventory-payments

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch wave-6-inventory-payments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 15

🤖 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 @.eslintrc.json:
- Around line 15-17: Update the rules section in .eslintrc.json to restore
TypeScript-specific lint coverage, including the existing `@typescript-eslint`
checks that prevent explicit any and related type-safety violations. If the
rules were renamed or migrated, configure equivalent TypeScript-aware rules
while preserving the current prefer-const setting.

In `@migrations/015_inventory_and_payments.sql`:
- Around line 80-86: Update the existing indexes on pre-existing orders and
products tables—idx_orders_stripe_session_id,
idx_orders_stripe_payment_intent_id, idx_orders_payment_status, and
idx_products_inventory—to use CREATE INDEX CONCURRENTLY, while leaving the
orders_audit indexes unchanged. Ensure this migration runs outside a transaction
block because concurrent index creation is not permitted within one.

In `@migrations/016_orders_user_scoped_writes.sql`:
- Around line 38-47: Update the “Users can insert items on their own orders”
policy for public.order_items to remove user-facing INSERT authorization,
keeping order_items writes restricted to the service-role/server-validated path.
Do not retain the current ownership-based WITH CHECK policy, since it permits
client-controlled price and quantity values.
- Around line 27-31: Restrict the “Users can update their own orders” policy so
clients cannot modify payment, status, or financial fields through Supabase
REST. Prefer removing this UPDATE policy entirely and preserving required
order-status writes through the service-role path; otherwise add a BEFORE UPDATE
trigger that rejects user-initiated changes to payment_status, status, total,
subtotal, and stripe_payment_intent_id.

In `@package.json`:
- Line 59: Remove the redundant `@types/uuid` dependency from the package.json
dependencies or devDependencies, while keeping the uuid package at ^14.0.1
unchanged.

In `@src/app/`(dashboard)/orders/page.tsx:
- Around line 164-169: Update the order selection element in the orders.map
rendering to use a semantic button while preserving its existing styling and
fetchOrderDetails(order.id) activation. Ensure each order card is
keyboard-focusable and announced as an interactive control, without changing the
surrounding order data or click behavior.

In `@src/app/api/checkout/route.ts`:
- Around line 88-179: The checkout flow should make pending orders retry-safe
and avoid orphaned records. Use the existing idempotencyKey to find or upsert a
single pending order before inserting order items, reuse its orderId on retries,
and ensure item creation does not duplicate entries. In the
createCheckoutSession failure path and the stripe_session_id update failure
path, delete the associated order and items before returning the error, while
preserving successful Stripe-session reuse.
- Around line 95-98: Update the checkout payload’s shipping field to use
cartData.shipping directly instead of recomputing it from total, subtotal, and
tax. Keep the existing subtotal, tax, and total mappings unchanged.

In `@src/app/api/orders/`[id]/route.ts:
- Around line 17-21: Update the Supabase initialization in the route handler
around getSupabase and supabase.auth.getUser to bind the incoming request
context, passing the request or using the established request-scoped server
helper so cookies or tokens are available. Preserve the existing user lookup
flow while ensuring authenticated requests no longer use a fresh context-free
client.

In `@src/app/api/webhooks/stripe/route.ts`:
- Around line 94-108: Update handleCheckoutSessionCompleted to check the fetched
order’s current status before calling decrementInventory, allowing inventory
processing only for pending orders and returning or otherwise preserving the
existing outcome for already-processed orders. Alternatively, make the order
update and inventory transition conditional on pending → processing so Stripe
webhook redeliveries cannot decrement inventory twice.
- Around line 201-219: Update the payment_intent.payment_failed handling around
restoreInventory so inventory is restored only when this order has a recorded
prior stock reservation or decrement from checkout.session.completed. Avoid
restoring based solely on the presence of order_items, and make the guard
idempotent so duplicate webhook deliveries cannot restore inventory more than
once; preserve the existing cancelled and failed payment status updates.

In `@src/lib/inventory/manager.ts`:
- Line 71: Replace the any casts on the Supabase clients in the inventory
manager with a properly typed client using Database, and extend the Functions
definitions in database.types.ts with the required RPC argument and return types
so the existing calls remain type-safe.
- Around line 76-87: Update the decrement_product_inventory RPC handling in the
inventory loop to destructure its returned data and validate data?.[0]?.success
in addition to error. Treat a false or missing success flag as a failed
inventory decrement and return false, preventing the order from being marked
paid when stock is insufficient.

In `@src/lib/stripe/checkout.ts`:
- Around line 27-31: Update the CheckoutSessionRequest flow and checkout session
metadata so metadata.user_id receives the authenticated user’s actual UUID, not
request.customerId, which remains the email used by customer_email. Add and
propagate a separate userId field from the checkout route through the checkout
creation logic, preserving customerId’s existing email behavior.
- Around line 8-16: Update the checkout line-item construction around price_data
so it no longer assigns item.productId to the unsupported product_data.id field.
Use price_data.product when referencing an existing Stripe Product, or store the
identifier in product_data.metadata if creating product data inline, while
preserving the existing pricing and quantity values.

🪄 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

Run ID: 3fd07c66-8b39-4420-821d-190c63fa9523

📥 Commits

Reviewing files that changed from the base of the PR and between 96b7897 and 7d53ec8.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (16)

• .eslintrc.json
• migrations/015_inventory_and_payments.sql
• migrations/016_orders_user_scoped_writes.sql
• next-env.d.ts
• package.json
• src/app/(dashboard)/orders/page.tsx
• src/app/api/checkout/route.ts
• src/app/api/orders/[id]/route.ts
• src/app/api/webhooks/stripe/route.ts
• src/lib/inventory/index.ts
• src/lib/inventory/manager.ts
• src/lib/stripe/checkout.ts
• src/lib/stripe/client.ts
• src/lib/stripe/index.ts
• src/lib/stripe/types.ts
• src/types/database.types.ts

[coderabbitai]

Actionable comments posted: 3

Caution

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

⚠️ Outside diff range comments (3)

src/lib/inventory/manager.ts (2)

68-107: 🗄️ Data Integrity & Integration | 🔴 Critical | ⚡ Quick win

Prevent permanent inventory leaks on partial decrement failures.

When decrementing multiple items in a loop, a failure midway through (e.g., the second item is out of stock) causes the function to return false immediately. Because the previously processed items were already committed to the database, their stock is permanently leaked.

Track successfully decremented items and roll them back via restoreInventory before aborting to ensure data consistency.

🛡️ Proposed compensation logic

 export async function decrementInventory(
   items: OrderLineItem[]
 ): Promise<boolean> {
   const supabase = getSupabaseAdmin();
+  const successfulItems: OrderLineItem[] = [];
 
   try {
     // Decrement inventory for all items using atomic RPC function
     for (const item of items) {
       const { data, error } = await supabase.rpc('decrement_product_inventory', {
         product_id: item.product_id,
         quantity: item.quantity,
       });
 
       // decrement_product_inventory returns `table(success boolean,
       // inventory_after integer)` -- a request for MORE stock than is
       // available is a valid, successful SQL call (no `error`) that
       // returns success=false. Checking only `error` here previously let
       // an insufficient-stock result silently pass through as if the
       // decrement had happened, oversellling the product.
       const result = Array.isArray(data) ? data[0] : data;
 
       if (error || !result?.success) {
         console.error(
           `Failed to decrement inventory for product ${item.product_id}:`,
           error || `RPC returned success=false (inventory_after=${result?.inventory_after})`
         );
+        // Rollback previously decremented items before failing
+        if (successfulItems.length > 0) {
+          await restoreInventory(successfulItems);
+        }
         return false;
       }
 
+      successfulItems.push(item);
+
       // Invalidate cache for this product
       const cacheKey = `inventory:${item.product_id}`;
       await redis.del(cacheKey);
     }

🤖 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/lib/inventory/manager.ts` around lines 68 - 107, Update
decrementInventory to track each successfully decremented item and, before
returning false for a later RPC failure or exception, compensate for all prior
decrements by calling restoreInventory with the processed items. Preserve the
existing success checks and cache invalidation, and ensure rollback is attempted
before aborting the operation.

---

109-142: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Continue restoring remaining items when a partial failure occurs.

If increment_product_inventory fails for a single item (e.g., due to a transient network error), returning false immediately abandons the restoration of all remaining items in the loop, permanently losing their stock.

Record the failure but continue processing the rest of the array so you maximize stock recovery.

🛡️ Proposed fix to continue on error

 export async function restoreInventory(items: OrderLineItem[]): Promise<boolean> {
   const supabase = getSupabaseAdmin();
+  let allSuccess = true;
 
   try {
     // Restore inventory if order failed using atomic RPC function
     for (const item of items) {
       const { data, error } = await supabase.rpc('increment_product_inventory', {
         product_id: item.product_id,
         quantity: item.quantity,
       });
 
       // Same success-flag check as decrementInventory -- increment_product_inventory
       // also returns table(success boolean, inventory_after integer).
       const result = Array.isArray(data) ? data[0] : data;
 
       if (error || !result?.success) {
         console.error(
           `Failed to restore inventory for product ${item.product_id}:`,
           error || 'RPC returned success=false'
         );
-        return false;
+        allSuccess = false;
+        continue;
       }
 
       // Invalidate cache
       const cacheKey = `inventory:${item.product_id}`;
       await redis.del(cacheKey);
     }
 
-    return true;
+    return allSuccess;
   } catch (error) {
     console.error('Error restoring inventory:', error);
     return false;
   }
 }

🤖 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/lib/inventory/manager.ts` around lines 109 - 142, Update restoreInventory
to record per-item failures from increment_product_inventory, including RPC
errors or unsuccessful results, then continue processing the remaining items
instead of returning immediately. Track whether any item failed and return false
after the loop if so, while preserving cache invalidation for successful
restorations and the existing outer exception handling.

src/app/api/webhooks/stripe/route.ts (1)

68-138: 🗄️ Data Integrity & Integration | 🔴 Critical | 🏗️ Heavy lift

Status guard does not cover the update-failure window — inventory can still be double-decremented.

The guard at lines 76-81 only protects redeliveries that arrive after the status was successfully changed to processing. But if decrementInventory succeeds (line 111) and then the order update at lines 127-134 fails, the handler throws — the catch in POST releases the idempotency key, yet the order is still pending because the update never persisted. Stripe's retry then re-enters this handler, passes the status === 'pending' guard, and calls decrementInventory a second time, corrupting stock. The inline comment at lines 68-75 asserts the guard handles this, but it cannot: the guard depends on the very update that failed.

Consider making the decrement and the pending → processing transition atomic (single RPC/transaction) or recording an explicit inventory_decremented flag committed before/with the decrement, so a retry after a failed status write cannot decrement again.

🤖 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/app/api/webhooks/stripe/route.ts` around lines 68 - 138, Make the
inventory decrement and the pending-to-processing transition atomic in the
handler around decrementInventory and the subsequent orders update, or persist
an equivalent inventory_decremented marker atomically with the decrement. Ensure
a retry after the status update fails cannot invoke decrementInventory again,
while preserving the existing non-pending early-return 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 `@migrations/017_orders_checkout_idempotency.sql`:
- Around line 17-19: Update the idx_orders_checkout_idempotency_key creation
statement to use CONCURRENTLY, matching the concurrent index pattern from
migration 015 while preserving its unique, partial-index conditions.

In `@src/app/api/checkout/route.ts`:
- Around line 104-170: The order creation flow around the
`supabase.from('orders').insert` call must handle PostgreSQL error code `23505`
as an idempotency race. When that conflict occurs, re-query the pending order
using `checkout_idempotency_key`, reuse its ID, and continue without returning a
500; preserve the existing error response for other insert failures.

In `@src/app/api/webhooks/stripe/route.ts`:
- Around line 228-236: Update the processing-order branch around
restoreInventory so its boolean result is checked explicitly. If inventory
restoration fails or is partial, surface the failure and route the webhook into
the existing reconciliation path, preventing order cancellation and successful
webhook completion; retain the current flow only when restoration succeeds.

---

Outside diff comments:
In `@src/app/api/webhooks/stripe/route.ts`:
- Around line 68-138: Make the inventory decrement and the pending-to-processing
transition atomic in the handler around decrementInventory and the subsequent
orders update, or persist an equivalent inventory_decremented marker atomically
with the decrement. Ensure a retry after the status update fails cannot invoke
decrementInventory again, while preserving the existing non-pending early-return
behavior.

In `@src/lib/inventory/manager.ts`:
- Around line 68-107: Update decrementInventory to track each successfully
decremented item and, before returning false for a later RPC failure or
exception, compensate for all prior decrements by calling restoreInventory with
the processed items. Preserve the existing success checks and cache
invalidation, and ensure rollback is attempted before aborting the operation.
- Around line 109-142: Update restoreInventory to record per-item failures from
increment_product_inventory, including RPC errors or unsuccessful results, then
continue processing the remaining items instead of returning immediately. Track
whether any item failed and return false after the loop if so, while preserving
cache invalidation for successful restorations and the existing outer exception
handling.

🪄 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

Run ID: 9ec2804e-28a9-4b5f-9526-5ae9f93ad003

📥 Commits

Reviewing files that changed from the base of the PR and between 7d53ec8 and 189bf9e.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (13)

• .eslintrc.json
• migrations/015_inventory_and_payments.sql
• migrations/016_orders_user_scoped_writes.sql
• migrations/017_orders_checkout_idempotency.sql
• package.json
• src/app/(dashboard)/orders/page.tsx
• src/app/api/checkout/route.ts
• src/app/api/orders/[id]/route.ts
• src/app/api/webhooks/stripe/route.ts
• src/lib/inventory/manager.ts
• src/lib/stripe/checkout.ts
• src/lib/stripe/types.ts
• src/types/database.types.ts

💤 Files with no reviewable changes (1)

• package.json

[coderabbitai]

🚀 Performance & Scalability | 🟠 Major | ⚡ Quick win

Use CONCURRENTLY to avoid locking writes on the orders table.

Building this index normally will acquire a SHARE lock that blocks all incoming order writes for the duration of the build. Add concurrently to prevent downtime on this critical path (matching the pattern you successfully applied in migration 015).

⚡ Proposed fix

-create unique index if not exists idx_orders_checkout_idempotency_key
+create unique index concurrently if not exists idx_orders_checkout_idempotency_key
   on public.orders(checkout_idempotency_key)
   where checkout_idempotency_key is not null;

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	create unique index if not exists idx_orders_checkout_idempotency_key
	on public.orders(checkout_idempotency_key)
	where checkout_idempotency_key is not null;
	create unique index concurrently if not exists idx_orders_checkout_idempotency_key
	on public.orders(checkout_idempotency_key)
	where checkout_idempotency_key is not null;

🧰 Tools

🪛 Squawk (2.59.0)

[warning] 17-19: During normal index creation, table updates are blocked, but reads are still allowed. Use concurrently to avoid blocking writes.

(require-concurrent-index-creation)

🤖 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 `@migrations/017_orders_checkout_idempotency.sql` around lines 17 - 19, Update
the idx_orders_checkout_idempotency_key creation statement to use CONCURRENTLY,
matching the concurrent index pattern from migration 015 while preserving its
unique, partial-index conditions.

Source: Linters/SAST tools

[coderabbitai]

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify unique constraint / index on checkout_idempotency_key
fd -e sql . migrations | xargs rg -nP 'checkout_idempotency_key' -C2
rg -nP 'unique|UNIQUE' migrations/017*.sql 2>/dev/null || true

Repository: Hex-Tech-Lab/hex-diva

Length of output: 1194

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== route excerpt =="
sed -n '1,260p' src/app/api/checkout/route.ts | cat -n

echo
echo "== migration 017 =="
sed -n '1,120p' migrations/017_orders_checkout_idempotency.sql | cat -n

echo
echo "== unique-violation handling in repo =="
rg -n "23505|unique violation|duplicate key|checkout_idempotency_key|idx_orders_checkout_idempotency_key" src migrations

Repository: Hex-Tech-Lab/hex-diva

Length of output: 13419

---

Handle the checkout idempotency race on unique conflict.

The unique index prevents duplicate orders, but two simultaneous requests can still both miss the lookup; the second .insert() will hit 23505 and currently return a 500. Catch that case, re-read the pending order by checkout_idempotency_key, and reuse it instead of failing.

🤖 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/app/api/checkout/route.ts` around lines 104 - 170, The order creation
flow around the `supabase.from('orders').insert` call must handle PostgreSQL
error code `23505` as an idempotency race. When that conflict occurs, re-query
the pending order using `checkout_idempotency_key`, reuse its ID, and continue
without returning a 500; preserve the existing error response for other insert
failures.

[coderabbitai]

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '\n== route file outline ==\n'
ast-grep outline src/app/api/webhooks/stripe/route.ts --view expanded || true

printf '\n== restoreInventory references ==\n'
rg -n "restoreInventory" src/app/api/webhooks/stripe/route.ts src -g '!**/*.map' || true

printf '\n== relevant route slice ==\n'
sed -n '180,280p' src/app/api/webhooks/stripe/route.ts

printf '\n== restoreInventory definition candidates ==\n'
fd -a "restoreInventory" src || true
rg -n "async function restoreInventory|const restoreInventory|function restoreInventory" src -g '*.ts' -g '*.tsx' || true

Repository: Hex-Tech-Lab/hex-diva

Length of output: 4465

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo 'route slice'
nl -ba src/app/api/webhooks/stripe/route.ts | sed -n '210,260p'

echo
echo 'restoreInventory search'
rg -n "restoreInventory" src -g '*.ts' -g '*.tsx'

echo
echo 'order processed marking search'
rg -n "processed|webhook" src/app/api/webhooks/stripe/route.ts

Repository: Hex-Tech-Lab/hex-diva

Length of output: 211

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

printf '== manager.ts around restoreInventory ==\n'
sed -n '1,220p' src/lib/inventory/manager.ts

printf '\n== route.ts POST handler ==\n'
sed -n '260,380p' src/app/api/webhooks/stripe/route.ts

Repository: Hex-Tech-Lab/hex-diva

Length of output: 8222

---

Handle restoreInventory failures separately — the boolean result is ignored, so a failed or partial restore still falls through to order cancellation and webhook success. Since restoreInventory can stop mid-loop, don’t rely on a retry throw here; surface the failure and route it into reconciliation instead.

🤖 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/app/api/webhooks/stripe/route.ts` around lines 228 - 236, Update the
processing-order branch around restoreInventory so its boolean result is checked
explicitly. If inventory restoration fails or is partial, surface the failure
and route the webhook into the existing reconciliation path, preventing order
cancellation and successful webhook completion; retain the current flow only
when restoration succeeds.

[TechHypeXP]

Closing as superseded — this entire PR is built on custom Stripe checkout/webhook code (src/app/api/checkout, src/app/api/webhooks/stripe, src/lib/stripe/*) against a pre-ADR-012 architecture. main has since archived all custom checkout/cart/payment pages in favor of Shopify-native checkout (see archive/custom-commerce-pages). Every substantive file in this diff is tied to that abandoned path, and the merge conflicts on checkout/route.ts and webhooks/stripe/route.ts are modify/delete conflicts against files main deliberately removed, not resolvable textual conflicts.