fix(cloudflare): Auto-instrument classes re-exported from the worker entry - #23282
Draft
JPeer264 wants to merge 4 commits into
Draft
fix(cloudflare): Auto-instrument classes re-exported from the worker entry#23282JPeer264 wants to merge 4 commits into
JPeer264 wants to merge 4 commits into
Conversation
JPeer264
requested review from
isaacs and
mydea
and removed request for
a team
August 11, 2026 12:13
Contributor
size-limit report 📦
|
Member
Author
|
Put back to draft. It seems there is a double instrumentation by accident |
JPeer264
force-pushed
the
jp/instrument-agent-vite-plugin
branch
2 times, most recently
from
August 25, 2026 16:23
0b08c7b to
08f2abe
Compare
…entry
The Vite auto-instrument transform only wrapped classes declared in the entry
module. An entry that just aggregates its Durable Objects, Agents and Workflows
from other files — `import { MyAgent } from './agent'; export { MyAgent }`, or
`export { MyAgent } from './agent'` — got no instrumentation at all, leaving
manual `instrument*WithSentry` wrapping as the only option.
An import binding cannot be reassigned, so instead of renaming a declaration the
transform now re-points those specifiers at a fresh wrapper binding and rebuilds
the export statement, carrying unrelated specifiers over verbatim.
Agent detection was blind to the same shapes: `collectAgentCandidates` only
considered local classes, so a re-exported Agent was never even offered to the
cross-module base-class walk that already knew how to resolve it.
Star re-exports (`export * from './do'`) still cannot be wrapped — they name no
binding — so the warning stays, reworded to say that rather than blaming
re-exports in general.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`export { X } from './x'` has no local binding: the specifier's "local" name is
an export of the *source* module. Matching it against `workerEntrypointClasses`
— which structural detection populates from this module's own AST — wrapped a
re-exported class whenever an unrelated local class happened to share its name.
Configured names are unaffected; those are keyed by exported name, which is what
wrangler binds.
Also covers the re-export path for Workflows and WorkerEntrypoints, which went
through it untested.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…worker entry Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
JPeer264
force-pushed
the
jp/instrument-agent-vite-plugin
branch
from
August 26, 2026 05:59
08f2abe to
8746c0b
Compare
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 8746c0b. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Agents are different, they need special care on top of the wrangler config. Because they are marked as DurableObjects, but have a different wrapper, they need extra hacks within the Vite plugin.
Issue
Before, specific type of import/exports didn't work properly and caused manual instrumentation again: https://github.com/sergical/cuzz/blob/4ec6080865e37491ff240007bbe886f907ad1de7/src/worker/index.ts#L11-L15
Solution(s)
First one
We had to add a
agentreturn insideresolveWrapperKind, to correctly identify Agents in there as well, so we know when to addinstrumentAgentWithSentryinstead ofinstrumentDurableObjectWithSentrySecond one
When a class gets exported right away, we need to change that export:
needs to be changed to the following in order to wrap it:
This should fix what was needed before: getsentry/sentry-docs#18944
Clanker description
The Vite auto-instrument transform only wrapped classes declared in the entry module. An entry that just aggregates its Durable Objects, Agents and Workflows from other files —
import { MyAgent } from './agent'; export { MyAgent }, orexport { MyAgent } from './agent'— got no instrumentation at all, leaving manualinstrument*WithSentrywrapping as the only option.An import binding cannot be reassigned, so instead of renaming a declaration the transform now re-points those specifiers at a fresh wrapper binding and rebuilds the export statement, carrying unrelated specifiers over verbatim.
Agent detection was blind to the same shapes:
collectAgentCandidatesonly considered local classes, so a re-exported Agent was never even offered to the cross-module base-class walk that already knew how to resolve it.Star re-exports (
export * from './do') still cannot be wrapped — they name no binding — so the warning stays, reworded to say that rather than blaming re-exports in general.