Crons

Litestore runs scheduled background jobs through Inngest. They publish scheduled content, retry failed deliveries, send digests and clean up old data. Read this page when you need to find out when a job runs or when you add a new one.

Ten jobs/cron.* modules define 10 scheduled Inngest functions. Litestore registers each one in app/api/inngest/route.ts, and Inngest calls them all through /api/inngest.

You build each job with inngest.createFunction(config, { cron }, handler). The schedule is a string literal in the file. The database has no schedule table, and the admin has no screen for editing one.

Most jobs set TZ=Europe/Warsaw in their expression. The four frequent ones (*/10, */15 and */30 minutes) run on plain UTC expressions.

Schedule

Currency rates

currencyRatesRefresh runs on TZ=Europe/Warsaw 0 18 * * *. The job runs at 18:00 on purpose. The ECB publishes its rates at about 16:00 CET, and running two hours later means each fetch gets that day's rates instead of yesterday's.

Abandoned carts

abandonedCartDetection runs on */30 * * * * and queries the database for idle carts. Litestore does not start a durable timer when a cart goes quiet. Nothing happens at the moment a cart goes idle, so there is no event to start a timer from. The job has to look for idle carts instead.

Idle time

The job measures idle time from lastCustomerActivityAt in modules/checkout/cart-activity.ts. That value is the latest of three timestamps:

non-deleted item updatedAt
checkoutStartedAt
createdAt

The job deliberately ignores Cart.updatedAt. Litestore's own background writes change updatedAt when they reserve stock, record attribution, apply a coupon, set shipping, clean up or merge carts. If the job used updatedAt, every one of those writes would reset the idle time even though the shopper did nothing.

Claims

Two runs of the job can overlap, and Inngest can retry a run. To avoid sending the event twice, the job claims each cart before it emits anything:

// Claim-then-act: atomically mark as processed BEFORE emitting so a
// retry or overlapping cron run can't re-send the abandoned event.
const claim = await db.cart.updateMany({
  where: { id: cart.id, abandonedEmailSentAt: null },
  data: { abandonedEmailSentAt: new Date() },
})
if (claim.count === 0) continue

If the emit then throws, the job clears abandonedEmailSentAt again. The next run picks the cart up again, instead of leaving it marked as sent with no email queued.

Cron scope

The job emits a cart.abandoned domain event and does nothing else. The recovery-drip workflow handles everything after that. It sends a follow-up and, hours later, a coupon, and it waits between them with step.sleep, which is a durable wait.

Litestore combines the two on purpose. A poll finds the abandoned cart, and a durable sleep spaces out the follow-ups.

The job cannot reach guest carts. The query requires customer: { email: { not: null } }, and the source notes that carts have no email column of their own. Recovering guest carts would need a migration that adds Cart.email.

Weekly cleanup

dataCleanup is the largest job in jobs/. Each retention window is a named constant at the top of the file. The job runs ten step.run sweeps.

The job deliberately leaves message-media/ alone. Those attachments are not Media rows, so the job has no way to check whether anything still uses them.

Adding crons

Built-in behavior

A new cron gets two things without extra work. When it runs out of retries, jobs/platform.failures.ts records a platform_job_failed Activity row. The Prisma middleware in platform/inngest.ts also passes db to your handler.

A new cron does not get idempotency. A run can overlap the previous one and can be retried. If your job increments a counter, sends something or claims a row, the query itself has to prevent doing it twice.

Related