Post-Fibers: can core server packages ship native async instead of transpiled generators? (async stack traces)

core
1

I hit a debugging wall in a Meteor 3.4 app and want to sanity-check the build-target reasoning before I open an issue, in case I’m missing something obvious.

A publication threw on the server. Here’s the entire stack trace that reached my error tracker:

TypeError: Cannot read properties of null (reading 'id')
  at asyncGeneratorStep (programs/server/packages/ddp-server.js:255)
  at _throw (programs/server/packages/ddp-server.js:276)
  at Subscription.error (packages/ddp-server/livedata_server.js:970)
  ... (third-party APM wrapper frames)

That’s it. Every frame is the DDP generator trampoline or a wrapper. The two things I actually needed — which publication threw, and the original error underneath the tracking path aren’t in it. The async parent chain is gone before the trace is even captured.

Here’s my read on why, and I’d like to know if it’s right. ddp-server ships to Atmosphere already transpiled: async/await lowered to generators through Babel’s _asyncToGenerator/asyncGeneratorStep helper. V8’s zero-cost async stack traces only stitch frames across a native await. Route execution through a hand-rolled generator trampoline instead and there’s nothing left for V8 to attach the parent frames to. So on Node 22 the runtime is capable of good async traces, but the shipped generator lowering throws that away before it can.

The part I don’t understand: Fibers is gone in 3.0. I’d assumed that coroutine model was the main reason server code went through a generator-shaped transform in the first place. So why does the os build still do it?

Concretely:

  1. Is it a shared Babel preset across the web.browser.legacy and os archs, a conservative Node baseline for the server target, or something load-bearing I can’t see?
  2. Is there any supported way for an app author to opt their own server bundle out of the async-to-generator transform? I went looking and couldn’t find a knob.
  3. If someone retargeted the core server build to native async on Node ≥18, what breaks? Microtask-timing differences between the trampoline and native await are the thing I’d worry about.
  4. Has anyone actually measured the perf or bundle delta? I’d guess native is marginally faster and smaller, but honestly I care about the stack traces far more than the nanoseconds.

The payoff I’m after is real traces for server errors: publication throws, observer-callback failures, method rejections, instead of everything bottoming out at asyncGeneratorStep with no app context. If there’s interest I’m happy to benchmark or test a build.

(The specific null-deref above turned out to be a missing guard in the APM package, already patched. This isn’t about that bug — it’s about why a normal server error gives me a trace I can’t use.)