🦋 Changeset detected

Latest commit: 01c5756

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler

Changeset Review

Summary

All changesets look good

Detailed Review

reject-v8-coverage-provider.md

• Version Type: patch - appropriate for clearer error messaging
• Changelog Quality: Good - explains the problem and solution clearly
• Markdown Headers: None
• Notes: Well-documented changeset explaining why V8 coverage is rejected and the alternative

c3-frameworks-update-13276.md, c3-frameworks-update-13275.md, c3-frameworks-update-13278.md, c3-frameworks-update-13279.md, c3-frameworks-update-13274.md

• Status: Skipped (dependency update changesets for create-cloudflare - per rule wrangler tail #5)

tender-dryers-ask.md

• Version Type: patch - appropriate for autoconfig fix
• Changelog Quality: Good - explains the behavioral change
• Markdown Headers: None

email-service-commands.md

• Version Type: minor - appropriate for new CLI commands
• Changelog Quality: Good - comprehensive list of all new commands
• Markdown Headers: None (uses list format, not headers)

use-formatConfigSnippet-in-dev-compat-date.md

• Version Type: patch - appropriate for format fix
• Changelog Quality: Good - explains the fix clearly
• Markdown Headers: None

dependabot-update-13241.md, dependabot-update-13305.md

• Version Type: patch - appropriate for dependency updates
• Changelog Quality: Clear table format showing version changes
• Markdown Headers: None
• Notes: These are dependabot changesets for miniflare/wrangler (not create-cloudflare), so they are validated

all-fans-march.md

• Version Type: minor - appropriate for new feature (ReadableStream support)
• Changelog Quality: Good - explains the feature and its benefit (overcoming 1MB limit)
• Markdown Headers: None

calm-beers-help.md

• Version Type: minor - appropriate for experimental feature enhancement
• Changelog Quality: Good - notes the experimental nature of the feature
• Markdown Headers: None
• Experimental Feature Note: Includes "Note: The local explorer is a WIP experimental feature."

good-falcons-remain.md

• Version Type: minor - appropriate for UI overhaul
• Changelog Quality: Good - explains the styling changes
• Markdown Headers: None

images-chainable-handle.md

• Version Type: patch - appropriate for API alignment fix
• Changelog Quality: Good - explains the pattern change and references workerd PR
• Markdown Headers: None

c3-node-version-check.md

• Version Type: patch - appropriate for error message improvement
• Changelog Quality: Good - explains the problem and solution
• Markdown Headers: None

Now I have a thorough understanding of the changes. Let me analyze the key issue I spotted:

The main concern is in executeListDOObjects in do.ts (lines 265-283). For every object in the paginated list, it instantiates the DO stub and calls GET_DO_NAME_METHOD. This means:

1. Performance: Every listed DO gets instantiated just to fetch its name. For each DO in the list, a get() call is made which wakes up the DO (or creates it), and then an RPC call is made. With a default page size of 50, this means up to 50 DO instances get woken up on every list call. This is the main concern.

2. The void ctx.blockConcurrencyWhile(...) in the constructor (line 33) - the void means the promise is fire-and-forget from the constructor's perspective. While blockConcurrencyWhile will prevent concurrent requests from executing until it completes, the void here is correct since constructors can't be async. However, I should check if there's a race condition between the constructor's blockConcurrencyWhile and the GET_DO_NAME_METHOD call.

Actually, thinking more carefully: blockConcurrencyWhile gates all incoming requests to the DO until the callback resolves. So when GET_DO_NAME_METHOD is called via RPC, it won't execute until blockConcurrencyWhile has completed. This is correct.

Let me think about the performance issue more carefully. The DO instances are being woken up anyway in production to serve requests, and this is a local dev explorer tool. The concern is less critical in a local dev context. However, the name is already being persisted to SQLite - why not just read it directly from the SQLite file on disk instead of waking up every DO?

Actually, reading the SQLite file from disk would bypass the DO isolation. The current approach using stubs is the "correct" way to interact with DO storage. And since this is local dev only, the performance is acceptable.

Let me check one more thing - whether the name field could leak undefined into the JSON response when no name is found:

Looking at lines 277-279 of do.ts:

return {
    id,
    name,
    hasStoredData: true,
};

When name is undefined, JSON serialization will omit the property, which matches the test expectations (the unique-id DO entry in the snapshot doesn't have a name field). This is fine.

Let me also check the isHexId function and its implications for the URL routing:

The isHexId function at $objectId.tsx:28 checks for exactly 64 hex characters. If a user names their DO with a 64-character hex string (unlikely but possible), it would be incorrectly treated as an ID rather than a name. This is an edge case but worth noting.

Let me also verify the LocalDODriver constructor - when navigating by name, objectId is null and objectName is the value. The LocalDOConnection constructor checks if (!objectId && !objectName) which would throw if both are falsy. Since null is falsy, this means objectName must be truthy. This is fine since the UI guards against empty input.

Wait, but there's another issue. In the $objectId.tsx loader, objectId and objectName are derived from the same URL param. When isHexId is false, objectName is set to params.objectId. But then LocalDODriver is constructed with new LocalDODriver(namespace.id, null, objectName). The LocalDOConnection will then query using durable_object_name, which calls idFromName() on the server side. This means the DO will be created if it doesn't exist yet - which is expected behavior for idFromName. So that's fine.

Overall the PR looks well-structured. The only actionable concern I see is the performance implication of waking up every DO on list, but given this is a local dev tool and the page is limited to 50, it's pragmatically acceptable. Let me check if there's anything else.

Looking at the void on line 33 of do-wrapper.worker.ts - the returned promise from blockConcurrencyWhile is explicitly voided. This is correct since constructors can't return promises, and blockConcurrencyWhile is designed for exactly this pattern.

One thing I notice: the GET_DO_NAME_METHOD is synchronous (no async), but the type GetDONameMethod in constants.ts declares it as () => string | undefined (not Promise<string | undefined>). When called over RPC via stub[GET_DO_NAME_METHOD](), it returns a promise (since RPC is async). The await in the caller handles this correctly. This is fine.

Let me do one final check on whether the __miniflare_do_name table gets created for non-SQLite DOs:

In the constructor (line 34), ctx.storage.sql is accessed. For non-SQLite DOs, ctx.storage.sql would be undefined, so the if (sql) guard prevents any table creation. Good.

But wait - GET_DO_NAME_METHOD (line 61) also accesses this.ctx.storage.sql for the fallback path. For non-SQLite DOs where ctx.id.name is undefined, this would try to access sql which would be undefined, and the if (sql) guard handles it. Good.

I'm satisfied this PR is well-implemented. No bugs, no security issues, no backward compatibility concerns. The approach is sound for a local dev tool.

LGTM

github run

npm i https://pkg.pr.new/create-cloudflare@13133

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@13133

npm i https://pkg.pr.new/miniflare@13133

npm i https://pkg.pr.new/@cloudflare/pages-shared@13133

npm i https://pkg.pr.new/@cloudflare/unenv-preset@13133

npm i https://pkg.pr.new/@cloudflare/vite-plugin@13133

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@13133

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@13133

npm i https://pkg.pr.new/wrangler@13133

commit: 01c5756

Codeowners approval required for this PR:

• ✅ @cloudflare/wrangler