You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/docs/architecture.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,10 +11,10 @@ Inngest is built from a small set of independent subsystems. Each one owns a sin
11
11
1. Your service (or another function) sends an event to the **Event API**.
12
12
2. The event is fanned out to every function that subscribes to it; this is **run scheduling**.
13
13
3. Each new run, and every step within it, becomes an item on the **queue**.
14
-
4. The **executor** pulls from the queue and invokes your function, either over HTTP (**serve**) or over a persistent worker connection (**Connect**).
14
+
4. The **executor** pulls from the queue and invokes your function, either over HTTP (**serve**) or over a persistent worker connection (**[Connect](/docs/setup/connect)**).
15
15
5. The result of each step is written to the **state store**, and the next step is enqueued. This repeats until the function completes.
16
16
17
-
Steps that wait, such as [`step.waitForEvent`](/docs/features/inngest-functions/steps-workflows/wait-for-event), [`step.invoke`](/docs/guides/invoking-functions-directly), `step.sleep`, and [`cancelOn`](/docs/features/inngest-functions/cancellation/cancel-on-events), leave a **pause** in the state store instead of an immediate queue item. The pause is resumed by an incoming event, a signal, or a timer.
17
+
Steps that wait, such as [`step.waitForEvent`](/docs/features/inngest-functions/steps-workflows/wait-for-event), [`step.invoke`](/docs/guides/invoking-functions-directly), [`step.sleep`](/docs/features/inngest-functions/steps-workflows/sleeps), and [`cancelOn`](/docs/features/inngest-functions/cancellation/cancel-on-events), leave a **pause** in the state store instead of an immediate queue item. The pause is resumed by an incoming event, a signal, or a timer.
18
18
19
19
## Subsystems
20
20
@@ -106,7 +106,7 @@ When something looks wrong, the subsystem usually narrows itself down quickly:
106
106
107
107
-`inngest.send()` is failing or slow → **Event API**.
108
108
- Events are accepted but functions never start → **Scheduler** or **Queue**.
109
-
- Runs start but get stuck mid-flight → **Executor**, your **serve endpoint**, or **Connect Gateway**.
109
+
- Runs start but get stuck mid-flight → **Executor**, your **serve endpoint**, or **[Connect](/docs/setup/connect) Gateway**.
110
110
-[`step.waitForEvent`](/docs/features/inngest-functions/steps-workflows/wait-for-event) or [`cancelOn`](/docs/features/inngest-functions/cancellation/cancel-on-events) is not firing → **Scheduler** or **State store** (pauses).
111
111
- Dashboards and the REST API are slow but runs are fine → **REST API**, not the runtime.
0 commit comments