Using this ticket for a follow up task to enable orchestrion in dev mode. Clanker output for the astro case below 🔽
Context
Follow-up from #22830 (auto-wiring the orchestrion bundler plugin in @sentry/astro).
Orchestrion build-time instrumentation works in production (astro build + node ./dist/server/entry.mjs), but a dev-mode e2e run (astro dev) against the same app did not produce DB spans.
Observed
Running the astro-7-orchestrion e2e suite with TEST_ENV=development (astro dev --port 3030):
- Dev server starts cleanly (Astro v7.1.6), DB containers healthy.
- The
http.server transaction for GET /db-ioredis / GET /db-mysql does arrive.
- But no
db spans are attached → the transaction-with-span assertion times out.
- The production run of the exact same tests passes.
Runtime subscribers register fine in dev ([orchestrion:ioredis] subscribing…, [orchestrion:mysql] subscribing…); it's the publisher-side transform that appears not to fire.
Suspected mechanism (not fully confirmed)
The publisher injection is the code-transformer's transform hook, which splices diagnostics_channel.publish into the driver source. That hook is not build-gated, so in principle it can run in dev serve — but only if astro dev routes the instrumented CJS node_modules packages (ioredis, mysql) through Vite's SSR transform pipeline.
The plugin uses:
config() → ssr.noExternal: [instrumented modules] to force-bundle them, andapplyToEnvironment(env => env.config.consumer === 'server').
The hypothesis is that under Astro 7's dev SSR module loader, the instrumented deps are not pulled through the transform (externalized / loaded raw via Node, and/or the dev SSR environment's consumer doesn't satisfy the applyToEnvironment guard), so transform never sees the driver source. This needs confirmation by instrumenting the transform (log each id it receives in dev) or tracing Astro 7 dev SSR resolution.
Scope note
All existing orchestrion e2e apps (nuxt-4-orchestrion, sveltekit-2-orchestrion) are production-only, so this is not an astro-specific regression — it's an open question about whether build-time orchestrion can/should work under any Vite dev server. Tracking here so the dev-mode gap is investigated rather than assumed.
Using this ticket for a follow up task to enable orchestrion in dev mode. Clanker output for the astro case below 🔽
Context
Follow-up from #22830 (auto-wiring the orchestrion bundler plugin in
@sentry/astro).Orchestrion build-time instrumentation works in production (
astro build+node ./dist/server/entry.mjs), but a dev-mode e2e run (astro dev) against the same app did not produce DB spans.Observed
Running the
astro-7-orchestrione2e suite withTEST_ENV=development(astro dev --port 3030):http.servertransaction forGET /db-ioredis/GET /db-mysqldoes arrive.dbspans are attached → the transaction-with-span assertion times out.Runtime subscribers register fine in dev (
[orchestrion:ioredis] subscribing…,[orchestrion:mysql] subscribing…); it's the publisher-side transform that appears not to fire.Suspected mechanism (not fully confirmed)
The publisher injection is the code-transformer's
transformhook, which splicesdiagnostics_channel.publishinto the driver source. That hook is not build-gated, so in principle it can run in dev serve — but only ifastro devroutes the instrumented CJSnode_modulespackages (ioredis,mysql) through Vite's SSR transform pipeline.The plugin uses:
config()→ssr.noExternal: [instrumented modules]to force-bundle them, andapplyToEnvironment(env => env.config.consumer === 'server').The hypothesis is that under Astro 7's dev SSR module loader, the instrumented deps are not pulled through the transform (externalized / loaded raw via Node, and/or the dev SSR environment's
consumerdoesn't satisfy theapplyToEnvironmentguard), sotransformnever sees the driver source. This needs confirmation by instrumenting the transform (log eachidit receives in dev) or tracing Astro 7 dev SSR resolution.Scope note
All existing orchestrion e2e apps (
nuxt-4-orchestrion,sveltekit-2-orchestrion) are production-only, so this is not an astro-specific regression — it's an open question about whether build-time orchestrion can/should work under any Vite dev server. Tracking here so the dev-mode gap is investigated rather than assumed.