7a340ad135
The core competitive moat (PRODUCT_STRATEGY.md §3.1): checkout can no
longer complete without a valid, still-available slot, on any Shopify
plan. User confirmed writing Functions in JS rather than Rust — no Rust
toolchain was available in this environment, and IMPLEMENTATION_PLAN.md §1
explicitly allows JS as a fallback ("Rust preferred, JS acceptable").
- app/services/holds.server.ts: Redis-backed soft slot-holds with TTL.
Hold creation is a Lua script (EVAL) — the "does this slot have room"
check and the reservation itself have to be one atomic Redis operation,
or two concurrent requests can both read "one spot left" and both
succeed. Outstanding holds per slot live in a sorted set scored by expiry
(so eviction is just ZREMRANGEBYSCORE, no separate expiry job needed to
read a correct count), and a repeat request from the same cart renews
its own hold instead of competing against the capacity gate again.
- app/routes/apps.scheduling.hold.tsx: public app-proxy endpoint the widget
calls the moment a shopper picks a slot — reserves capacity BEFORE the
cart attribute is written, since the attribute alone is just two
shoppers racing to write the same field.
- extensions/datetime-widget: now fetches the cart token, requests a hold
first, and only writes cart attributes on success; shows an error and
refreshes the slot list if it loses the race.
- app/services/booking.server.ts + webhooks.orders.create.tsx: converts an
order's dd_* cart attributes into a confirmed Booking (idempotent on
orderId — webhooks redeliver), releases the matching hold, and writes a
`delivery_datetime.booking` order metafield so the slot is visible on the
order record natively (IMPLEMENTATION_PLAN.md §5.2/§2). Deliberately does
NOT re-check capacity and reject at this point — by the time an order
exists, payment has happened; that's the Function's job, earlier.
- webhooks.orders.cancelled.tsx: marks the Booking cancelled, freeing its
capacity.
- extensions/validation-slot (Cart/Checkout Validation Function): blocks
checkout when the cart's dd_* attributes are missing or incomplete — a
shopper who bypasses the widget entirely (clears the attribute, calls the
cart API directly) still cannot check out, because this runs inside
Shopify's own checkout, not the browser. Scope note documented in
evaluate.js: this doesn't yet re-validate against a live capacity
snapshot at the moment checkout completes ("has since been taken" in
§3.1) — Functions can't call our DB, and a metafield-snapshot refresh
pipeline for that is unscoped work; the 10-minute hold TTL is the interim
mitigation for that specific race.
- extensions/delivery-customization: relabels every delivery option to the
shopper's actual chosen method + date ("Pickup — Aug 25" instead of a
generic carrier label), directly fixing the "estimated delivery date on a
pickup order" complaint §3.1 names. payment-customization is deliberately
NOT built yet — there's no configurable payment-method rule for it to
enforce until later phases add one; shipping a no-op Function serves
nothing.
- Prisma: added Booking (no SlotHold table — Redis is the sole source of
truth for holds, per §4's own "(Redis-backed)" annotation; mirroring it
into Postgres would just be a sync-consistency burden with no benefit).
- Both Function extensions are hand-scaffolded from Shopify's documented
JS Function structure (same interactive-login limitation as the Theme
App Extension) — README.md flags that `shopify app function schema`
should be run before deploying to confirm the input queries still match
the live schema.
New tests/integration/ suite (separate vitest config, needs live
Redis+Postgres — `docker compose up -d` locally, a services: block in CI)
holds the tests that can't be meaningfully mocked: the slot-hold
concurrency test CLAUDE.md calls out as non-negotiable (20 concurrent
requests for 1 unit of capacity → exactly 1 succeeds; 30 for 5 → exactly 5;
release-then-retry; TTL expiry; same-cart renewal) and the full
hold-to-booking lifecycle including idempotency on webhook redelivery.
Both Functions' pure decision logic is separately unit-tested (11 tests).
60 total tests now pass (52 unit + 8 integration).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
99 lines
3.5 KiB
TypeScript
99 lines
3.5 KiB
TypeScript
import { afterAll, describe, expect, it } from "vitest";
|
|
import redis from "../../app/lib/redis.server";
|
|
import { countActiveHolds, releaseHold, tryCreateHold, type SlotIdentity } from "../../app/services/holds.server";
|
|
|
|
// The concurrency test CLAUDE.md calls out as non-negotiable: "Slot-holds
|
|
// (Redis, TTL) prevent last-slot double-booking — this has a dedicated
|
|
// concurrency test that must pass." This needs a real Redis — the
|
|
// atomicity guarantee comes from a Lua script Redis runs single-threaded,
|
|
// which a mock can't meaningfully exercise. Run via `npm run test:integration`
|
|
// against the docker-compose Redis (or CI's redis service).
|
|
|
|
function uniqueSlot(): SlotIdentity {
|
|
return {
|
|
shopDomain: "concurrency-test.myshopify.com",
|
|
locationId: "loc_test",
|
|
method: "PICKUP",
|
|
slotStartIso: `2026-08-25T13:00:00.000Z#${Math.random().toString(36).slice(2)}`,
|
|
};
|
|
}
|
|
|
|
describe("tryCreateHold concurrency", () => {
|
|
afterAll(async () => {
|
|
await redis.quit();
|
|
});
|
|
|
|
it("lets exactly one of many concurrent requests claim the last unit of capacity", async () => {
|
|
const slot = uniqueSlot();
|
|
const capacity = 1;
|
|
const contenders = 20;
|
|
|
|
const results = await Promise.all(
|
|
Array.from({ length: contenders }, (_, i) => tryCreateHold(slot, `cart-${i}`, capacity)),
|
|
);
|
|
|
|
const successes = results.filter((r) => r.success);
|
|
expect(successes).toHaveLength(1);
|
|
|
|
const activeCount = await countActiveHolds(slot);
|
|
expect(activeCount).toBe(1);
|
|
});
|
|
|
|
it("allows exactly `capacity` concurrent holds, no more, no fewer", async () => {
|
|
const slot = uniqueSlot();
|
|
const capacity = 5;
|
|
const contenders = 30;
|
|
|
|
const results = await Promise.all(
|
|
Array.from({ length: contenders }, (_, i) => tryCreateHold(slot, `cart-${i}`, capacity)),
|
|
);
|
|
|
|
expect(results.filter((r) => r.success)).toHaveLength(capacity);
|
|
expect(await countActiveHolds(slot)).toBe(capacity);
|
|
});
|
|
|
|
it("releasing a hold frees capacity for a subsequent request", async () => {
|
|
const slot = uniqueSlot();
|
|
const capacity = 1;
|
|
|
|
const first = await tryCreateHold(slot, "cart-a", capacity);
|
|
expect(first.success).toBe(true);
|
|
|
|
const blocked = await tryCreateHold(slot, "cart-b", capacity);
|
|
expect(blocked.success).toBe(false);
|
|
|
|
await releaseHold(slot, "cart-a");
|
|
|
|
const afterRelease = await tryCreateHold(slot, "cart-b", capacity);
|
|
expect(afterRelease.success).toBe(true);
|
|
});
|
|
|
|
it("an expired hold no longer counts against capacity", async () => {
|
|
const slot = uniqueSlot();
|
|
const capacity = 1;
|
|
|
|
// A negative TTL means it's already expired the instant it's created.
|
|
const first = await tryCreateHold(slot, "cart-expired", capacity, -1000);
|
|
expect(first.success).toBe(true);
|
|
|
|
const second = await tryCreateHold(slot, "cart-fresh", capacity);
|
|
expect(second.success).toBe(true);
|
|
expect(await countActiveHolds(slot)).toBe(1);
|
|
});
|
|
|
|
it("the same cart re-requesting the same slot does not consume a second unit", async () => {
|
|
const slot = uniqueSlot();
|
|
const capacity = 1;
|
|
|
|
const first = await tryCreateHold(slot, "cart-repeat", capacity);
|
|
expect(first.success).toBe(true);
|
|
|
|
// ZADD on an existing member updates its score rather than adding a
|
|
// second entry, so a shopper re-confirming the same slot (e.g. a retried
|
|
// request) doesn't burn extra capacity against themselves.
|
|
const second = await tryCreateHold(slot, "cart-repeat", capacity);
|
|
expect(second.success).toBe(true);
|
|
expect(await countActiveHolds(slot)).toBe(1);
|
|
});
|
|
});
|