Document raw Containers API alongside Container class - #33093
thomasgauvin wants to merge 13 commits into
Conversation
AI Review✅ Reviewed 👉 Fix in your agent 👈Fix the following review findings in PR #33093 (https://github.com/cloudflare/cloudflare-docs/pull/33093).
Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification.
- If you disagree, explain why.
- If you need clarification before deciding, ask those questions.
- Then share your plan for which issues to tackle and in what order.
After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.
The comment must come before the commit because the next review reads PR comments.
## Style Guide
- S-1195645a | src/content/docs/containers/concepts/architecture.mdx:123 | Semicolon joins two independent clauses
The sentence "The Durable Object becomes inactive when it stops receiving requests; the timeout can keep the container available while the Durable Object sleeps." joins two independent clauses with a semicolon. Per the writing-style rules, break it into two sentences.
- S-01025b58 | src/content/docs/containers/guides/migrate-to-durable-object-container-api.mdx:25 | Missing serial comma before final conjunction
The three replacement options `ctx.container.start()`, `signal()`, and `destroy()` are joined by `and`/`or` without a comma before the final `or`. Per the serial comma rule, the comma must appear before the final top-level conjunction.Style Guide
Not reviewed (1)
Resolved (2) · Dismissed (0)
Commands
|
Review coverage✅ All 5 ownership areas are covered. ✅ 5 areas already covered
CODEOWNERS mappings for displayed areas (5)
|
|
Review triage for findings on 285ad23:
The other findings are fixed and validated in the isolated local PR worktree. No commit or push has been made yet. |
| constructor(ctx: DurableObjectState, env: Env) { | ||
| super(ctx, env); | ||
| ctx.blockConcurrencyWhile(() => | ||
| ctx.container!.setInactivityTimeout(10 * 60 * 1000), |
There was a problem hiding this comment.
This example could use a container: Container; property that gets init in the constructor, and then users dont have to use ! operator when accessing ctx.container.
There was a problem hiding this comment.
Addressed in #33093: the short API comparison snippet now checks for a configured container instead of using the non-null assertion.
| ### Container shutdown | ||
|
|
||
| The Container class sets [`sleepAfter`](/containers/reference/container-class/#sleepafter) to 10 minutes by default. Its default [`onActivityExpired()`](/containers/reference/container-class/#onactivityexpired) implementation signals the container to stop after that period without activity. You can change the duration or override the hook. | ||
| With the Durable Object Container API, call [`setInactivityTimeout()`](/containers/api/durable-object-container/#setinactivitytimeout) to let the runtime stop an inactive container. You can also stop a container with [`signal()`](/containers/api/durable-object-container/#signal) or [`destroy()`](/containers/api/durable-object-container/#destroy). |
There was a problem hiding this comment.
There will be questions around setinactivitytimeout. In general, we should explain that setInactivityTimeout triggers when the Durable Object goes to sleep, use it so the container can be kept around while the DO is inactive (which is when requests do not come in).
There was a problem hiding this comment.
Addressed in #33093: the shutdown section now explains inactivity in terms of the Durable Object receiving no requests and the timeout keeping its container available while the Durable Object sleeps.
|
|
||
| constructor(ctx: DurableObjectState, env: Env) { | ||
| super(ctx, env); | ||
| ctx.blockConcurrencyWhile(() => |
There was a problem hiding this comment.
In these examples I do not think we shouldbe using blockConcurrencyWhile.
| private async startAndWaitForPort(): Promise<void> { | ||
| const container = this.ctx.container!; | ||
| if (!container.running) { | ||
| container.start(); |
There was a problem hiding this comment.
Do we have any examples with monitor()? We should add an incentive for LLMs to use monitor() to track when the container exits (and track if there is any errors.
There was a problem hiding this comment.
Addressed in the stacked examples PR #33681: the backend direct-API example now uses monitor() to log both container exit and errors. The status-hooks example also demonstrates monitor().
|
We should add an example somewhere for LLMs to read that showcase how to keep the container "always running", and add an RPC in the DO that exposes a destroy() + destry alarm. |
| enableInternet: true, | ||
| env: { | ||
| ENV_VAR: env.ENV_VAR, | ||
| WORKER_SECRET: env.WORKER_SECRET, |
There was a problem hiding this comment.
No blockConcurrencyWhile, I recommend just exposing a start() method on this DO as it does not seem to do anything.
In general, let's discourage starting in the constructor for LLMs
There was a problem hiding this comment.
Agreed about not starting in the constructor. The raw environment-variable variant was removed from #33093 and deferred from #33681 because its options overlap the separate start() work in #33531. The remaining direct-API examples in #33681 start from methods or requests without blockConcurrencyWhile().
| ctx.blockConcurrencyWhile(async () => { | ||
| if (!ctx.container!.running) { | ||
| ctx.container!.start({ | ||
| image: env.CONTAINER_IMAGE, |
| if (this.ctx.container!.running) { | ||
| throw new Error("Container is already running"); | ||
| } | ||
| this.ctx.container!.start({ image, enableInternet: true, env }); |
There was a problem hiding this comment.
This is a great example, let's add monitor() too?
Summary
Focuses this PR on the Containers documentation information architecture:
Testing