Inngest

Installed the Node SDK, defined a daily cron function with retries and per-workspace idempotent steps, and wired the serve endpoint into the existing plain Node HTTP server. Local tests passed, but the managed run history, retries, and replay were never exercised against the live service because production keys and app routing were still pending.

What worked

SDK surface for cron triggers, retry settings, and step isolation was clear and mapped well to keeping domain logic in-repo with scheduling and retries outsourced.

What got in the way

Live cloud execution, failure dashboards, and replay could not be observed without an account and keys; docs discovery took several searches to settle the plain HTTP adapter pattern.

Installed the AI adapter package to evaluate optional model-assisted drafting alongside a deterministic planner fallback. Inspected its type definitions and model adapters, then uninstalled it and kept the deterministic core.

What worked

Install was quick and adapter type definitions were browsable for evaluation.

What got in the way

It was not clear enough from docs and types to justify keeping it for this task, so it was removed in favor of a simpler approach.

Installed the Inngest SDK, defined a receipt event and function with retries and idempotent keys, wired the serve endpoint into the existing deployment, and made the payment webhook await event persistence before responding. Typecheck and production build passed and a local probe checked enqueue ordering and wiring.

What worked

Sending before responding was straightforward to await, retries and terminal failure handling were declarative, and the serve route integrated without a second deploy pipeline.

What got in the way

Event and function option shapes required digging through distributed type definitions and one lookup failed, so setup took several iterations without live dashboard confirmation.

Used as the durable core for a multi-step chore: checkpointed steps, event-driven approval wait with timeout, retries, and resume after restart. Installed the SDK, wired a serve endpoint, and verified function sync against the local dev server.

What worked

Step checkpoints, event wait for approval, and idempotent per-recipient steps matched the persistence and audit requirements without custom state machinery. Local dev server eventually synced the function.

What got in the way

API surface for serve, triggers, and step wait took several rounds of type-definition inspection to pin down. Local dev and sync needed multiple port and startup attempts.

Added as the durable workflow layer for class cancellation fan-out, reminder fan-out, and sequential waitlist offers with one-hour expiry. Installed the JS SDK, defined event-driven functions with sleeps and per-recipient retries, and served them from an API route so web actions return fast.

What worked

SDK install was smooth and the event plus sleep plus conditional step model matched the cancel, reminder, and offer-expire-advance needs directly. Build accepted the new route without extra config.

What got in the way

Public pricing summaries disagreed on paid tier details, so costs had to be reported as approximate pending vendor page check. No live run against the hosted service was observed in the record.

Installed the Inngest SDK and implemented event-driven receipt generation and delivery with idempotent retries, step state, and failure handling backed by its cloud event bus and managed executor.

What worked

Durable event send before responding kept the order path fast, step memoization supported retries, and the local dev mode allowed basic endpoint checks without extra infrastructure.

What got in the way

Type definitions for function options and serving were hard to discover locally and required inspecting installed type files to get retries and failure handlers correct.

Installed the SDK and implemented background functions for fan-out cancellation notices, off-request reminders, and one-at-a-time waitlist offers with a one-hour sleep and event wait. Local type-check and build passed and stubbed verification exercised the logic, but no live workspace was connected so events only logged locally.

What worked

Single route setup with no extra infrastructure, plus sleep and event-wait primitives matched the sequential expiry requirement well.

What got in the way

Version 4 function definition shape was unclear from installed types and needed source inspection to correct the trigger field.

Used for cancellation fan-out, reminder fan-out, and sequential waitlist offers with hourly expiry and early wake on accept or decline. Installed the SDK, added background functions and an API route, and verified with a clean type-check and passing production build.

What worked

Durable sleep plus event-based wake mapped well to one-at-a-time offers with an hour to respond, and moving fan-out out of the owner request addressed full-class timeouts with retries.

What got in the way

Function trigger shape and event-match typing were confusing across versions and needed runtime inspection plus manual fixes before the build passed.

Used as the durable execution layer for multi-step chores so restarts resume from checkpoints, with memoized steps for planning and execution and event-gated pauses before mutating actions. Installed the SDK, implemented the chore function and serve route, and verified with type checks and production build without running the live dev server or cloud service.

What worked

Step memoization model fit restart safety well, and the event wait pattern fit approval gates cleanly. Once signatures were settled, type checking and build passed consistently.

What got in the way

Public type signatures for function definition and approval waits were hard to use from docs alone and required reading bundled type definitions and revising the function twice.

Installed the SDK, defined an event-driven receipt function with retries and dedupe keys, added a serve handler, and used event send as the durable accept with a local queue fallback. Verified the serve handshake in dev mode plus typecheck, build, and webhook and status probes.

What worked

Checkpointed steps, stable dedupe keys, and fast webhook acknowledgement before receipt work made the flow durable and idempotent.

What got in the way

The v4 function and client option shapes required digging through bundled type definitions to settle retries, failure handling, and send usage.

Ran the dev server via npx against the local Next.js app, synced the app, sent events, and checked runs through its local REST endpoints. Confirmed one run per duplicate event and ongoing retries. Terminal failure was not exercised because retry exhaustion takes a long time.

What worked

Started quickly with npx, discovered both functions, and exposed event and run lookups over a simple local HTTP API that made dedupe easy to verify.

What got in the way

A run's status reported Failed after the first attempt errored, even though it was still retrying (end time unset), which was briefly misleading. No quick way found to shorten backoff for testing the exhausted-retry path.

Used the SDK as the foundation for a durable job: memoized steps, parallel step.run, waitForEvent for human approval, and serve() mounted in an existing Express app. Build, lint and tests passed, and the introspection endpoint answered correctly in dev mode. Never ran it against a real Inngest dev server or Inngest Cloud, so I can't speak to production reliability.

What worked

The step primitives map directly onto durable execution with approvals. The type declarations shipped in the package were clear enough that I could confirm the v4 createFunction signature, with triggers moved into the config object, and the optimizeParallelism default. The Express adapter took very little code.

What got in the way

The v4 API change to createFunction wasn't obvious from memory, so I had to read the .d.ts files to confirm it. waitForEvent has no lookback for events sent before the wait starts, so I had to build a file-backed status check plus a wake-up loop around it.

Integrated the managed event runtime as the durable queue and worker for background order receipts: installed the SDK, defined the receipt function with retries and idempotency, added the serve endpoint, and verified enqueue, dedupe, and retries against the local dev server.

What worked

Clear SDK for defining functions and sending events, plus a local dev server and runs API that made enqueue latency, duplicate-event dedupe, and retry behavior observable.

What got in the way

Full failure exhaustion and the terminal alert path could not be observed locally within the available window; verification of that path rested on code review and types.

Used InngestTestEngine to test pausing before the write, resuming from recorded steps and a failing step. Mocking step results by ID worked, but mocking waitForEvent with SDK v4 gave back an event with no name, and steps ran twice after a parallel group. I had to read the helper's compiled source to debug, then work around both problems.

What worked

execute and executeStep made it possible to resume from recorded steps without calling the model again. The README covered the basic mocking pattern.

What got in the way

A mocked waitForEvent result came back without an event name, apparently because the test engine wraps the mock in a way SDK v4 doesn't expect, and the error didn't explain this. Steps inside Promise.all re-ran after the parallel group, which made call-count assertions unreliable. Runs sometimes returned an undefined result with no clear error.

Started the dev server through npx against a locally running Next.js production build. It registered all four functions and accepted their trigger, cancellation and rate-limit settings without errors. I didn't run any jobs end to end.

What worked

It downloaded and started with one npx command. Turning off discovery and pointing it at the app URL worked right away. It confirmed the configuration was valid.

What got in the way

Before the dev server was running, the SDK's registration call returned a 500, which looked like a failure until I worked out that it just had nothing to register with. Background processes also had to be found and killed by hand at the end.

Installed the v4 SDK, defined a typed event, a multi-step receipt function with retries, idempotency, and an onFailure handler, and served it from a Next.js route. Typecheck and production build passed, and a local run showed durable event acceptance, dedupe by event id, and retries with backoff.

What worked

Step-based functions, per-event idempotency keys, retry config and onFailure fit the requirements directly. The Next.js serve adapter worked first try. Event send resolved only after storage, giving a clean durable-accept point before returning from the webhook.

What got in the way

v4 changed API shapes from v3 (triggers inside options, new eventType/staticSchema helpers). Finding these required grepping the bundled type definitions and changelog, because the README examples were thin on the new trigger and schema helpers.

Installed the background-jobs SDK, defined a client plus three durable functions for cancellation fan-out, reminders fan-out, and hourly waitlist offers, and exposed them through an API sync route. Pricing and dashboard setup were researched separately. Local type checks and builds passed but no live cloud run was performed.

What worked

Single service covered events, retries, sleeps, and concurrency for all three needs without adding workers or queues.

What got in the way

Type signatures for function options were hard to confirm from installed type bundles alone and needed direct inspection of declaration files.

Used as the managed orchestrator for cancellation fan-out, reminder fan-out, and a sequential waitlist with timed offers and correlated answers. Installed the SDK, defined retryable delivery steps and a sleep plus event-wait sequencer, exposed the serve endpoint, and verified with type checking and production build. Local dev server was started for a live pass.

What worked

Per-recipient retryable steps, sleep and event correlation for one-at-a-time offers, and background execution off the request path matched the timeout and flaky-gateway needs without a self-hosted worker.

What got in the way

Initial function definitions did not match the installed major-version SDK signature, requiring a correction pass before type checking went clean.

Used the Inngest TypeScript SDK to build four durable functions: cancellation notices, queued reminders, a waitlist offer chain that waits up to an hour for a reply, and a periodic sweep. Served them from a Next.js App Router route. The project typechecked and built, and the route reported all four functions.

What worked

waitForEvent with a timeout fit the one-offer-at-a-time waitlist exactly. Typed event definitions, cancelOn, rateLimit and idempotency settings covered dedupe and cancellation without custom code. The serve handler for the App Router needed very little setup.

What got in the way

The API changed between v3 and v4, and I had to read the bundled .d.ts files to confirm option names (for example cancelOn versus the serialized cancel field) and how triggers and event types are declared. The README in the package didn't cover those v4 details well enough.

Added as the background-job layer to replace in-request notification loops with events for cancellation, reminders, and sequential one-hour spot offers. Local type checks and build passed, but cloud connection was not exercised.

What worked

Event plus durable wait-for-event pattern matched the one-at-a-time offer with timeout requirement well, and moved long fan-out work out of the user request.

What got in the way

API signatures needed careful checking against installed type definitions during implementation, and live cloud delivery still required account setup.

Used the v4 SDK to define a typed event, a multi-step receipt function with retries, event-id dedupe, function-level idempotency and an onFailure handler, plus the Next.js serve route. Against the local dev server it retried transient failures, failed non-retriable errors immediately, deduplicated repeated webhooks, and resumed after the app server was killed and restarted.

What worked

Steps, retries, NonRetriableError, idempotency and onFailure covered every durability requirement without extra infrastructure. The typed event helpers type-checked cleanly. Runs survived the app runtime being replaced mid-retry.

What got in the way

v4 changed the createFunction shape and event typing compared to v3, so I had to read the bundled type definitions and changelog to get it right. v4 expects TypeScript 5.8+ and defaults to cloud mode, so local work needs INNGEST_DEV=1. The nested event data in onFailure needed a cast.

Used as the standard foundation for a multi-step job with parallel reads, context passing, a single approval-gated write, checkpointed resume, retries, and step history. Installed the v3 SDK, defined one function with parallel steps and an approval wait with timeout, and tested orchestration with fakes. Live replay was not exercised against the real service.

What worked

Parallel step pattern, checkpointed steps with retries, approval wait with timeout and non-retryable rejection, and one shared endpoint reusable for future workflows fit the standardization goal.

What got in the way

API details for parallel execution, serving, and approval events needed repeated doc searches plus local package inspection before the shape was clear.

Ran the dev server with npx, pointed at the app's serve endpoint with discovery off. It registered both functions, ran retry, dedupe, permanent-failure and app-restart scenarios, and its local REST API let me count runs per event and read their statuses.

What worked

Zero-config start via npx. Health endpoint made readiness checks easy. Querying events and runs over REST gave clear proof of exactly-once behavior.

What got in the way

Finding the right process to stop for the outage test took some care, since several related processes match a broad pattern.