Inngest

Which part of the work does Inngest handle?

Inngest keeps track of the workflow and calls the code on your host. The code can run through a supported web address or in a worker you connect to Inngest.

An event is a message about something that happened, such as “a report was requested.” It can start a function with separate steps to read records, build the report and save it. Inngest coordinates the order, retries and waiting. The app still owns the request, permissions and finished file.

How do you prove the first workflow works?

Use the local Dev Server and one made-up report event to see the separate steps and their outcome.

1. 1
   Isolate the event and its destinations

   Use test code and a test database and file store. Keep real email and payments disconnected. Confirm the test event reaches only the test function before sending it.
2. 2
   Give the function a small job

   Connect the SDK and register the function with the local Dev Server. Send one event with a fake report ID. Make the read and write separate named steps so you can see which work completed.
3. 3
   Open the report from the test app

   Match the successful run to one file stored for the fake request. Before deploying, check the host’s timeout and what the app shows while a run is waiting.

What happens if the save step fails?

Inngest remembers the result of a completed step. A later failed step can retry without repeating the earlier completed step.

Put each effect that needs a retry boundary inside a step. The surrounding function can be evaluated again. A save, email or outside call may succeed before the step records its result. Use a stable operation key with the service or a duplicate-safe write so the retry cannot create a second effect.

A stable event ID can suppress duplicate starts within 24 hours. That limit applies to repeat events. Keep a separate rule for the actual operation when it must happen only once.

How long can the workflow wait?

A whole workflow can wait much longer than one step can run. Your host may stop a step sooner than Inngest does.

Inngest documents a two-hour maximum per step, subject to the host’s shorter timeout. Free allows a run to last 30 days including sleeps. Pro lists 90 days. Free lists five concurrent steps and Pro includes 100. Store large files outside run state. One step can return up to 4 MiB.

A scheduled report has a due time. Choose the time zone deliberately and check clock changes, then inspect when the run actually starts and finishes. Use a report period and owner as part of the stable operation ID when the same period must produce only one report.

How do runs and steps add up on the bill?

One function run and each counted step are separate executions. Your own hosting and any outside services can add their own charges.

A thousand reports with three steps each are about 4,000 base executions if every run uses all three steps, before extra work such as retries. Use the actual count of steps in your workflow.

On a small screen, scroll the table sideways to read every column.

What is safe to rerun or move?

Inspect the failed step first. A manual rerun creates a new run. It can start from the beginning or reuse earlier results and run again from a selected step.

A rerun uses the available function code. A rerun from a step reuses the recorded results before that step, and executes the selected step and what follows. Before choosing it, check whether later operations already succeeded and how repeats are handled. A bulk replay can start many new executions.

Cloud trace and log history is listed as 24 hours on Free and seven days on Pro. Bulk replay depends on event retention. Keep finished reports and their access rules in your app. Inngest documents a self-hosted server, but the current single-node mode is marked beta. Moving code does not by itself move waiting runs, history or schedules.