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
The Context API provides methods to manage the lifecycle of your Worker or Durable Object.
17
13
18
14
Context is exposed via the following places:
19
15
20
-
* As the third parameter in all [handlers](/workers/runtime-apis/handlers/), including the [`fetch()` handler](/workers/runtime-apis/handlers/fetch/). (`fetch(request, env, ctx)`)
21
-
* As a class property of the [`WorkerEntrypoint` class](/workers/runtime-apis/bindings/service-bindings/rpc) (`this.ctx`)
16
+
- As the third parameter in all [handlers](/workers/runtime-apis/handlers/), including the [`fetch()` handler](/workers/runtime-apis/handlers/fetch/). (`fetch(request, env, ctx)`)
17
+
- As a class property of the [`WorkerEntrypoint` class](/workers/runtime-apis/bindings/service-bindings/rpc) (`this.ctx`)
22
18
23
19
Note that the Context API is available strictly in stateless contexts, that is, not [Durable Objects](/durable-objects/). However, Durable Objects have a different object, the [Durable Object State](/durable-objects/api/state/), which is available as `this.ctx` inside a Durable Object class, and provides some of the same functionality as the Context API.
24
20
@@ -72,26 +68,26 @@ To use `ctx.exports`, you must use [the `enable_ctx_exports` compatibility flag]
72
68
73
69
`ctx.exports` provides automatically-configured "loopback" bindings for all of your top-level exports.
74
70
75
-
* For each top-level export that `extends WorkerEntrypoint` (or simply implements a fetch handler), `ctx.exports` automatically contains a [Service Binding](/workers/runtime-apis/bindings/service-bindings).
76
-
* For each top-level export that `extends DurableObject` (and which has been configured with storage via a [migration](/durable-objects/reference/durable-objects-migrations/)), `ctx.exports` automatically contains a [Durable Object namespace binding](/durable-objects/api/namespace/).
71
+
- For each top-level export that `extends WorkerEntrypoint` (or simply implements a fetch handler), `ctx.exports` automatically contains a [Service Binding](/workers/runtime-apis/bindings/service-bindings).
72
+
- For each top-level export that `extends DurableObject` (and which has been configured with storage via a [migration](/durable-objects/reference/durable-objects-migrations/)), `ctx.exports` automatically contains a [Durable Object namespace binding](/durable-objects/api/namespace/).
let greeting =awaitctx.exports.Greeter.greet("World")
92
-
returnnewResponse(greeting);
93
-
}
94
-
}
86
+
asyncfetch(request, env, ctx) {
87
+
let greeting =awaitctx.exports.Greeter.greet("World");
88
+
returnnewResponse(greeting);
89
+
},
90
+
};
95
91
```
96
92
97
93
In this example, the default fetch handler calls the `Greeter` class over RPC, like how you'd use a Service Binding. However, there is no external configuration required. `ctx.exports` is populated _automatically_ from your top-level imports.
@@ -106,22 +102,22 @@ Loopback Service Bindings in `ctx.exports` have an extra capability that regular
// Make a custom greeter that uses the greeting "Welcome".
145
-
let greeter =ctx.exports.Greeter({props: {greeting: "Welcome"}})
139
+
async fetch(request, env, ctx) {
140
+
// Make a custom greeter that uses the greeting "Welcome".
141
+
let greeter =ctx.exports.Greeter({props: {greeting: "Welcome" } });
146
142
147
-
// Greet the world. Returns "Welcome, World!"
148
-
let greeting =awaitgreeter.greet("World")
143
+
// Greet the world. Returns "Welcome, World!"
144
+
let greeting =awaitgreeter.greet("World");
149
145
150
-
returnnewResponse(greeting);
151
-
}
146
+
returnnewResponse(greeting);
147
+
},
152
148
} satisfiesExportedHandler<Env>;
153
149
```
154
150
@@ -170,8 +166,16 @@ When declaring an entrypoint class that accepts `props`, make sure to declare it
170
166
171
167
`waitUntil` is commonly used to:
172
168
173
-
* Fire off events to external analytics providers. (note that when you use [Workers Analytics Engine](/analytics/analytics-engine/), you do not need to use `waitUntil`)
174
-
* Put items into cache using the [Cache API](/workers/runtime-apis/cache/)
169
+
- Fire off events to external analytics providers. (note that when you use [Workers Analytics Engine](/analytics/analytics-engine/), you do not need to use `waitUntil`)
170
+
- Put items into cache using the [Cache API](/workers/runtime-apis/cache/)
171
+
172
+
:::caution[`waitUntil` has a 30-second time limit]
173
+
174
+
The Worker's lifetime is extended for up to 30 seconds after the response is sent or the client disconnects. This time limit is shared across all `waitUntil()` calls within the same request — if any Promises have not settled after 30 seconds, they are cancelled. When `waitUntil` tasks are cancelled, the following warning will be logged to [Workers Logs](/workers/observability/logs/workers-logs/) and any attached [Tail Workers](/workers/observability/logs/tail-workers/): `waitUntil() tasks did not complete within the allowed time after invocation end and have been cancelled.`
175
+
176
+
If you need to guarantee that work completes successfully, you should send messages to a [Queue](/queues/) and process them in a separate consumer Worker. Queues provide reliable delivery and automatic retries, ensuring your work is not lost.
0 commit comments