a2c78d703f
Some checks failed
CI / Lint, Unit & Integration Tests (push) Has been cancelled
Audited the implementation against DS_Delivery_Date_Time_App_Study.docx and closed the actionable gaps (see IMPLEMENTATION_REVIEW_2026-09-04.md). Core (code + unit tests, 156 green): - Wire excludeLocationsWithoutStock into resolveAvailabilityRequest; widget now sends variantIds so inventory-based location exclusion actually runs. - Live slot re-validation at checkout: new checkout-snapshot.server.ts writes a shop-metafield capacity snapshot; validation-slot's evaluateCheckout rejects a complete selection that has since filled / blacked out / closed / hit the daily cap / left the schedule. Refreshed on order webhooks and slot/blackout/location/enforcement edits. - Scopable checkout enforcement: Shop.enforcementMode (all|tagged|off) + enforcementTag, new app.settings.tsx admin page, honoured via the snapshot. - Per-day order cap: Location.dailyOrderCap threaded through getAvailability (dailyCap + consumedPerDate); admin field on the location screen. - Product-rule slot blocking: ProductRule.blockedStartMins, unioned in resolveProductRuleConstraints, enforced in the engine and resolveHoldRequest; admin field on the product rules screen. - Product-page placement: product-availability.liquid block + widget data-mode="preview" (read-only earliest-date line). - Second locale: datetime-widget fr.json / fr.schema.json. - Migration 20260904120000_review_gaps (apply with prisma migrate deploy). New Functions (source + unit tests; need `shopify app deploy` to ship): - extensions/payment-customization: cart.payment-methods.transform.run — hides cash-on-delivery / pay-in-store gateways on SHIPPING orders. - extensions/checkout-datetime/src: restored from a gitignored dist-only state — Plus native picker + Thank you / Order status confirmation blocks, all calling the existing checkout.scheduling.* routes (one capacity pool). tsconfig ships checkJs:false pending reconciliation with live checkout types. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
34 lines
1.4 KiB
TypeScript
34 lines
1.4 KiB
TypeScript
import { Worker } from "bullmq";
|
|
import { Redis } from "ioredis";
|
|
|
|
// BullMQ needs its own connection (can't share one used for pub/sub or with
|
|
// maxRetriesPerRequest set to a finite value in some modes) — kept separate
|
|
// from app/lib/redis.server.ts for that reason.
|
|
const connection = new Redis(process.env.REDIS_URL || "redis://127.0.0.1:6379", {
|
|
maxRetriesPerRequest: null,
|
|
});
|
|
|
|
// TODO (Phase 4): hold-expiry — release a SlotHold whose TTL has passed.
|
|
// TODO (Phase 9): notifications — send queued reminder/ETA messages.
|
|
// TODO (Phase 5+): capacity-recompute — recalculate denormalized capacity
|
|
// snapshots after config changes. The checkout snapshot
|
|
// (app/services/checkout-snapshot.server.ts) is refreshed inline on every
|
|
// order webhook and slot/blackout/enforcement edit, which covers all the
|
|
// cases that matter. A periodic sweep here would only keep the 30-day
|
|
// rolling horizon advancing on a store that takes zero orders and makes
|
|
// zero edits for a month — worth adding once offline-session storage is
|
|
// wired so this process can get an Admin client per shop.
|
|
const holdExpiryWorker = new Worker(
|
|
"hold-expiry",
|
|
async (job) => {
|
|
console.log("Processing hold-expiry job", job.id, job.data);
|
|
},
|
|
{ connection },
|
|
);
|
|
|
|
holdExpiryWorker.on("failed", (job, err) => {
|
|
console.error(`hold-expiry job ${job?.id} failed:`, err);
|
|
});
|
|
|
|
console.log("Worker started, listening for jobs...");
|