[Durable Objects] Document class exports#31650
Conversation
Review⏸️ Automatic reviews for this PR are paused. This PR has already received 2 automatic reviews. To run another review, a codeowner can comment
Code ReviewThis code review is in beta and may not always be helpful — use your judgment. Warnings (4)
Style Guide ReviewWarnings (10)
Suggestions (13)
CommandsOnly codeowners can run commands. Post a comment with the command to trigger it.
|
|
/review |
|
/review |
|
/full-review |
|
/bonk review this pr |
There was a problem hiding this comment.
This is a well-structured rewrite of the Durable Object lifecycle docs. The new exports-first flow is much clearer than the imperative migrations model, and preserving the legacy reference on its own page is the right call.
A couple of issues to fix before merging:
- Inconsistent error scenario tag — The prose and reconciliation sample use
tombstone_class_still_in_code, but the error reference table liststombstone_delete_class_still_in_code. These need to be aligned. - Tab indentation in the transfer section — Step 3 of the cross-Worker transfer flow uses tab characters instead of 4 spaces for indentation. In Markdown/MDX, tab-indented lines after a blank line can render as
<pre>code blocks rather than normal prose or component children, which breaks the<Steps>layout.
Everything else looks solid.
| | `config_export_not_in_code` | A live entry declares a class that the Worker code does not export. | Add the class to your code, or replace the entry with a tombstone. | | ||
| | `config_references_nonexistent_class` | A live entry declares a class that is neither in code nor provisioned. | Remove the entry, or add the class to your Worker code. | | ||
| | `orphaned_provisioned_namespace` | A namespace exists for a class that is neither in code nor declared. | Add a tombstone for the class, or add the class back to code and `exports`. | | ||
| | `tombstone_delete_class_still_in_code` | A `deleted` tombstone names a class that is still exported in code. | Remove the class from your code first, then deploy the tombstone. | |
There was a problem hiding this comment.
The reconciliation sample (line 406) and rename guidance (line 249) emit the generic info tag tombstone_class_still_in_code, but this table row uses tombstone_delete_class_still_in_code. Since the sample explicitly shows this tag for a renamed tombstone, the table should use the generic name and a matching description.
| | `tombstone_delete_class_still_in_code` | A `deleted` tombstone names a class that is still exported in code. | Remove the class from your code first, then deploy the tombstone. | | |
| | `tombstone_class_still_in_code` | A tombstone names a class that is still exported in code. | Remove the class from your code first, then deploy the tombstone. | |
|
|
||
| If the source Worker still needs to access `MyDO` after the transfer commits, update its `durable_objects.bindings` entry to point at the target Worker with `script_name`: | ||
|
|
||
| <WranglerConfig> | ||
| ```jsonc title="source Worker" | ||
| { | ||
| "durable_objects": { | ||
| "bindings": [ | ||
| { | ||
| "name": "MY_DURABLE_OBJECT", | ||
| "class_name": "MyDO", | ||
| "script_name": "target-worker" | ||
| } | ||
| ] | ||
| } | ||
| } | ||
| ``` | ||
| </WranglerConfig> | ||
|
|
||
| If the source Worker no longer needs to access `MyDO`, remove the binding when you remove `MyDO` from the source Worker's code. | ||
|
|
There was a problem hiding this comment.
This block (and the surrounding lines in step 3) is indented with tab characters instead of 4 spaces. In Markdown/MDX, tab-indented lines after a blank line can render as <pre> code blocks rather than normal prose or component children, which breaks the <Steps> layout. Please convert the tabs to 4 spaces to match the rest of the step.
|
Review submitted for PR #31650. What I reviewed
Feedback posted
Everything else looks solid — the structure is clean, links are consistent, and the decision to keep legacy docs on a separate page is the right one. |
Summary
Rewrites the Durable Objects class lifecycle reference around declarative
exports, while preserving the legacymigrationsarray documentation on a separate page.exportsschema, tombstone states, reconciliation output, storage rules, zero-downtime rename flow, and cross-Worker transfer flow.Screenshots (optional)
Documentation checklist