feat: add request layer lifecycle TracingChannels by logaretm · Pull Request #196 · pillarjs/router

logaretm · 2026-04-15T12:45:25Z

This PR adds a single tracing channel that emits structured lifecycle events (start, end, asyncStart, asyncEnd, error) for every middleware, route handler, and error handler execution.

This builds on #96 but uses tracing channels instead which enables context propagation out of the box.

Context shape

The context object is pretty minimal, providing both req and res enables APMs to figure out how to react to that specific payload.

{ req, res, layer }

The layer is the Layer instance. Subscribers use layer.name, layer.handle.length (4 for error handlers), and req.route (set when inside a matched route) to classify and name spans however they see fit.

Usage Example:

This is an example I've set up locally using a Sentry setup with this PR patched in:

const Sentry = require('@sentry/node')
// otel-tracing-channel is a simple tracing channel wrapper that patches in the OTEL context propagation
// atm otel doesn't support tracing channels, so this workaround is required for OTEL-based APMs
// the user wouldn't need this and typically they can set their own thing with ALS.
const { tracingChannel } = require('otel-tracing-channel')

Sentry.init({
  // ...
})

// Subscribe to express:request TracingChannel and create Sentry spans
const channel = tracingChannel('pillarjs.router.request', (ctx) => {
  const { layer, req } = ctx
  const isErrorHandler = layer.handle.length === 4
  const isRouteHandler = Boolean(req.route)

  const spanName = isRouteHandler
    ? `${req.method} ${req.route.path}`
    : isErrorHandler
      ? `error_handler - ${layer.name}`
      : `middleware - ${layer.name}`

  return Sentry.startSpanManual(
    {
      name: spanName,
      op: isRouteHandler ? 'http.handler' : isErrorHandler ? 'middleware.error' : 'middleware',
      attributes: {
        'express.name': layer.name,
        'http.request.method': req.method,
        'url.path': req.url,
        'url.full': req.originalUrl,
        ...(req.route && { 'http.route': req.route.path }),
        ...(req.query && Object.keys(req.query).length > 0 && {
          'url.query': JSON.stringify(req.query)
        }),
        ...(req.params && Object.keys(req.params).length > 0 && {
          'express.params': JSON.stringify(req.params)
        })
      }
    },
    (span) => span
  )
})

channel.subscribe({
  asyncEnd (ctx) {
    if (ctx.req.route) {
      ctx.span?.setAttribute('http.response.status_code', ctx.res.statusCode)
    }
    ctx.span?.end()
  },
  error (ctx) {
    ctx.span?.setStatus({ code: 2, message: ctx.error?.message })
    ctx.span?.end()
  }
})

// Express App
const express = require('express')
const app = express()

// Middleware
app.use(express.json())

app.use(function requestLogger (req, res, next) {
  console.log(`${req.method} ${req.url}`)
  next()
})

app.use(function addRequestId (req, res, next) {
  req.requestId = Math.random().toString(36).slice(2, 10)
  res.setHeader('x-request-id', req.requestId)
  next()
})

// Routes
app.get('/users/:id', function validateId (req, res, next) {
  if (isNaN(req.params.id)) {
    return res.status(400).json({ error: 'id must be a number' })
  }
  next()
}, function loadUser (req, res, next) {
  req.user = { id: req.params.id, name: 'Test User' }
  next()
}, function getUser (req, res) {
  res.json({ ...req.user, requestId: req.requestId })
})

This produces a waterfall view looking like this:

Note: The three spans that look the same at the bottom actually represent the three handlers executing for that route, it is up to the subscriber to decide which one is the route handler and how to name the other ones since it has access to layer.

Is tracing channels experimental?

We had this come up a few times during the initiative of pushing the adoption of dc across the ecosystem, most recently this was brought up and responded to by @Qard here:

Automattic/mongoose#16105 (comment)

Yes, it has mainly been left as experimental due to a lack of adoption, but also as a signal that we may make improvements as we learn from uses of it. That learning has largely already been absorbed and applied via recent PRs at this point. There are several improvements incoming, but none of those change the existing code, which will be left as-is, they add some additional systems to handle some more specific cases such as async iterators.

The TracingChannel API will be left as-is, likely forever at this point as it is very important to us to retain compatibility essentially indefinitely, because APM vendors have many customers using old Node.js versions even well beyond the EOL of Node.js itself [...]

Related work

This builds on Use diagnostics_channel in layers #96 but uses tracing channels
Related to feat: add diagnostics_channel support for app initialization expressjs/express#7041
Does the same as feat: add diagnostic channels for request lifecycle expressjs/express#7171 but uses tracing channels
Closes Support diagnostic channels expressjs/express#6353

Caveats

The channel name right now is pillarjs.router.request, in the original PR it was request but I think channel names need to have a relationship with the module name otherwise we risk duplication in the ecosystem.
Depending on the exact version of Node 18 certain behaviors are expected in this PR:
- Node versions without hasSubscribers will assume that there is a subscriber and will execute the traced path (with context object allocation). Multiple libraries like redis and mysql2 accepted this limitation.
- Node versions without tracingChannel support will just not offer tracing of any kind. The fallback here is NOOP.
It is up to APMs to represent the onion shape with nested handlers or flatten certain spans which is relatively easy if APMs have their own ALS context propagation strategy.
Tests running a node version that do not have tracingChannel will be skipped via describe.skip.

Add a single `express:request` TracingChannel that emits structured lifecycle events (start, end, asyncStart, asyncEnd, error) for every middleware, route handler, and error handler execution. Context shape: { req, res, layer } where layer is the Layer instance, giving subscribers access to layer.name, layer.handle.length (for error handler detection), and layer.route. Consumers decide how to classify and name spans based on these properties. Route dispatch wrapper layers (internal glue that calls route.dispatch) are excluded from tracing to avoid duplicate events. The actual user handlers inside the route are traced individually. Zero overhead when no subscribers are registered. The hasSubscribers check gates all context allocation and tracePromise wrapping. Refs: pillarjs#96 Refs: expressjs/express#6353

Extract handlePromise and unify the traced/untraced paths into a single try/catch and .then handler.

Express TracingChannel PR opened: pillarjs/router#196

Copilot

Pull request overview

Adds request-layer lifecycle instrumentation using Node.js diagnostics_channel TracingChannel, emitting structured events for middleware, route handlers, and error handlers to support APM-style tracing with context propagation.

Changes:

Add express:request TracingChannel integration in Layer request/error handling.
Introduce shared invocation helper to wrap handler execution and promise handling with tracing hooks.
Add a new test suite validating emitted events, context shape, and basic ordering/behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
lib/layer.js	Adds TracingChannel wiring and refactors handler invocation through a tracing-aware helper.
test/tracing.js	New mocha tests covering tracing context, handler types, and lifecycle event expectations.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Qard

Generally LGTM. I think we might want to validate if handled errors are still captured on the span prior to the handler though.

Qard · 2026-04-20T15:57:17Z

+  })
+
+  describe('error handler tracing', function () {
+    it('should trace error handlers (fn.length === 4)', function (done) {


Should this one capture the error even though it is considered handled overall?

Not entirely sure, APMs will usually have a global error handler or whatever to catch them so having them traced might be an overkill and may duplicate error emissions for those who don't dedup them.

WDYT?

But does it having a handler here result in the error not being present on the span for the layer that lead to the error handler? Whatever the behaviour is, I think it would be useful to validate it more explicitly in this particular test. We should have a clear model of what errors happen where.

Thanks! I added more tests to pin down various behaviors. Here is how errors flow right now:

No error handler (no app.use):

Route throws sync -> error channel publishes for the route layer. Router responds 500.

Route promise rejects -> error channel publishes for the route layer. Router responds 500.

With error handler:

Route throws sync -> error channel publishes for the route, handler runs, nothing on the error channel for the handler.

Route rejects async -> same, error channel publishes for the route, handler clean.

With error handler that also throws/rejects:

Route throws sync, handler throws -> error channel publishes twice, once per layer. Two legitimately failed executions.

Route rejects async, handler throws -> same.

For an APM: both throw cases produce two error events on the channel — one with ctx.layer pointing at the route, one at the error handler. Each event targets its own span, so the APM just marks both spans as failed.

In the case for next(err) then the child error handler span will be marked, not the parent one. Which is fine I suppose since it technically recovered as you've said.

Tests in 1ad1b9c.

Qard

Hmm...this handling seems a bit incorrect. If an error is unhandled it should definitely be reported. And even if it is handled we should still probably be reporting it so we can capture cases like a too permissive error handler silencing legitimate failures.

I think probably what we should be doing is always capturing the error and just adding some handled flag to the context to mark when it has been handled somehow. That way we can still report it with the detail that the application thinks it has been handled while still allowing human judgement to look at the span and see if that assessment actually makes sense.

Qard · 2026-04-20T19:32:19Z

+        })
+    })
+
+    it('should not emit error on the originating layer when next(err) is unhandled', function (done) {


This seems problematic. Unhandled errors should definitely always be observable.

Okay agreed, this could've become a real gap and it's always easier to dedup rather than miss events.

I pushed a fix to that in 90ed7e2 and adjusted the tests to pin that behavior.

Qard

I think it's in a reasonable state now. Might be good to also get a review from @rochdev or @Flarna for some more perspectives from other APM vendors. The specific error semantics I think might be a bit up to interpretation how they should be handled, but I think this shape should generally provide the context that is needed for the different ways we think about route errors. 🤔

Flarna · 2026-04-21T07:57:52Z

+ * @private
+ */
+
+const requestChannel = dc.tracingChannel && dc.tracingChannel('express:request')


Why is express:request channel used here?
I think it would be better to use a dedicated channel for router to allow consumers to decide on what to receive and how to handle it.
I think router component can be also used without express.

Good point, I don't think it has to be express prefixed but it needs a unique prefix for sure which is why I wanted some opinions on what it should be. My concern is router:request is too generic and can easily conflict with other names in the ecosystem.

I had this in the PR description:

The channel name right now is express:request, in the original PR it was request but I think channel names need to have a relationship with the module name otherwise we risk duplication in the ecosystem.

WDYT? Maybe pillarjs:router:request?

There seems to be a guideline.
So I guess the string to use would be pillarjs.router.request as tracing: prefix and event name postfix is added by dc.tracingChannel().

Doesn't seem like there is a consistent standard, docs do suggest that but others just went with lib:something:action formats.

Anyways I have no strong opinions here and I think as long as the name is unique enough, it is arbitrary. I renamed it to your suggestion 👍

I think it should just be router.request and not pillarjs.router.request. I say this because pillarjs is more like the organization name and that could change, and we might move this package to the expressjs organization (not saying we’ll do it now, but it could happen, so we shouldn’t be tied to the GitHub organization name).

Okay, I understand the concern. In that case, instead of using pillarjs, it’s better to use express, since it’s officially under the expressjs project.

How does Fastify handle it?

So should we go for express.request or express.router.request? To me its arbitrary but perhaps you have a strong opinion?

Fastify uses fastify.request.handler as seen here.

I think express.request is a bit too generic. There might be other parts in express describing the request lifecycle where the router component is not included.
e.g. express.request.router or express.router.request - tending towards express.request.router like fastify and hierarchic ordering.

Went with express.router.request since it describes the action better "Express's router is handling a request".

But happy to change to whatever that is acceptable to get this through.

Follows the Node.js TracingChannel naming guideline (dot-separated, module-scoped) and avoids the express-specific prefix since router is usable outside express.

Flarna · 2026-04-23T10:36:53Z

The actual data published by the tracing channel is the Layer instance, req and res objects.

If I understand the router module correct layer is an internal object which gets exposed here. Is there any guarantee that the relevant fields on that object stay intact? In fact they become part of the public interface here.

Also I don't find in the docs here that req.route is a public property. Is it safe for consumers to rely on that as it is seen part of public API and following Semver regarding changes?

In general I would love some section in the docs describing the diag channel and it's emitted data.

logaretm · 2026-04-23T20:51:17Z

Is it safe for consumers to rely on that as it is seen part of public API and following Semver regarding changes?

I can't answer that as it usually up to maintainers to decide this but I would say it does imply a public API contract and should be subject to smever.

As for the req.route, I'm not sure the AI created a snippet with it and it worked 🤷‍♂️

The layer object is strictly private today so this woulda actually expose it publicly.

In general I would love some section in the docs describing the diag channel and it's emitted data.

I think we have 3 options here:

Define a curated list of properties and expose those instead as public API.
Layer objects become a public API.
Continue to emit layer, but document a stable partial of it.

I think that would be up to the maintainers to decide, but all options work for us.

Qard · 2026-04-26T22:08:45Z

I generally suggest that event contents be considered public API surface, but I would not say that is mandatory as it is very common that diagnostics_channel events would be observing what would otherwise be internal implementation details. I would ask though that any exposure of internals be explicitly called out as internal to inform consumers that they should consume those events with defensive accesses to handle cases where shapes may change.

I don't fully think calling it public API surface is quite the right characterization of the intent.

bjohansebas · 2026-04-26T23:33:08Z

Also I don't find in the docs here that req.route is a public property. Is it safe for consumers to rely on that as it is seen part of public API and following Semver regarding changes?

Yes, it’s part of the public API (see

router/index.js

Line 281 in cb2a5fc

req.route = route

), so it should follow semver. That means anyone can depend on it. There might not be documentation (which I’ll add to my TODO once I’m back on the project, in case no one else has done it or if it doesn’t exist yet, since I don’t have time to verify it right now).

bjohansebas

Please also add documentation about this in the README.

logaretm · 2026-04-27T00:04:21Z

@bjohansebas I added a section on diagnostic channels and their payload, and marked layer as internal impl.

bjohansebas

Good job! I noticed a few details, and I'll open a PR to update the documentation on the website

edit: Note that the refactors I mentioned don't fix the bugs I found.

bjohansebas · 2026-07-15T00:18:11Z

+ * Check if the channel has subscribers.
+ */
+function shouldTrace (ch) {
+  return ch && ch.hasSubscribers !== false


Since we support Node 18.0.0, users on those versions will get true, because (undefined !== false) === true.

https://nodejs.org/api/diagnostics_channel.html#diagnostics_channeltracingchannelnameorchannels

Yep this is a trade off I suppose. I think we should then check for all channels own subscribers in that case.

bjohansebas · 2026-07-15T00:27:38Z

+- `req`: the incoming `http.IncomingMessage`
+- `res`: the `http.ServerResponse`
+- `layer`: the internal `Layer` instance being invoked (exposes `.name`, `.path`, `.handle`, etc.). Note that `Layer` is an internal implementation detail and its shape may change between releases.
+- `error`: the error passed to `next(err)`, when applicable


If someone did something like this, I know it's a very edge case, but it's still something we should fix since it's allowed by the way the router is designed:

router.get('/via-throw', function viaThrow (req, res, next) { throw 'route' // eslint-disable-line no-throw-literal }) router.get('/via-throw', (req, res) => res.end('second route ran'))

the error event would still be emitted, so it wouldn't be limited to just next(err). Even so, the request would still end up returning a 200.

I added an exception for these routing signals, should be ignored now.

bjohansebas · 2026-07-15T00:34:38Z

+      if (err && err !== 'route' && err !== 'router') {
+        ctx.error = err
+        // Explicitly publish the error to the error channel
+        requestChannel.error.publish(ctx)


Okay, we have a small bug here. When there are mounted sub-routers, if an error occurs, the parent router ends up publishing a duplicate error event. For example:

const http = require('node:http') const dc = require('node:diagnostics_channel') const Router = require('/home/bjohansebas/Dev/oss/pillarjs/router') const errorEvents = [] dc.tracingChannel('express.router.request').subscribe({ error (ctx) { errorEvents.push({ layer: ctx.layer && ctx.layer.name, handled: !!ctx.handled, message: ctx.error && ctx.error.message }) } }) function report (title) { console.log('\n%s', title) console.log(' error events published: %d %s', errorEvents.length, errorEvents.length === 1 ? '(OK)' : '(BUG: should be exactly 1, on the origin layer)') for (const e of errorEvents) { console.log(' layer=%s handled=%s message=%j', e.layer, e.handled, e.message) } errorEvents.length = 0 } async function run (router, path) { const server = http.createServer(function (req, res) { router(req, res, function (err) { res.statusCode = err ? 500 : 404 res.end(String(err || 'not found')) }) }) await new Promise(r => server.listen(0, r)) await fetch('http://localhost:' + server.address().port + path) await new Promise(r => setImmediate(r)) server.close() } async function main () { // Scenario A: mounted sub-router — a single next(err) in the inner handler, // recovered by an outer error handler. { const outer = new Router() const nested = new Router() nested.get('/bar', function innerHandler (req, res, next) { next(new Error('boom')) }) outer.use('/foo', nested) outer.use(function recover (err, req, res, next) { // eslint-disable-line no-unused-vars res.statusCode = 500 res.end(err.message) }) await run(outer, '/foo/bar') report('Scenario A: nested router (1 mount level)') } // Scenario A2: two mount levels — the error is republished on EVERY ancestor. { const outer = new Router() const mid = new Router() const deep = new Router() deep.get('/baz', function deepHandler (req, res, next) { next(new Error('boom')) }) mid.use('/bar', deep) outer.use('/foo', mid) outer.use(function recover (err, req, res, next) { // eslint-disable-line no-unused-vars res.statusCode = 500 res.end(err.message) }) await run(outer, '/foo/bar/baz') report('Scenario A2: nested router (2 mount levels)') } // Scenario B: error handler that forwards the error with next(err). { const router = new Router() router.get('/fail', function origin (req, res, next) { next(new Error('boom')) }) router.use(function forwardingHandler (err, req, res, next) { next(err) // does not handle it, delegates to the next one }) router.use(function recover (err, req, res, next) { // eslint-disable-line no-unused-vars res.statusCode = 500 res.end(err.message) }) await run(router, '/fail') report('Scenario B: error handler forwarding with next(err)') } } main()

In principle, the error event should only be published once.

That's a good catch. I will dedup the errors published in relation to the request object.

bjohansebas · 2026-07-15T00:41:56Z


+  try {
+    const ret = tracing
+      ? requestChannel.tracePromise(function () { return handlePromise(exec(wrappedNext)) }, ctx)


If someone does this, or manages to trigger it somehow:

router.get('/reject', async function rejectingHandler (req, res) { throw undefined // same as: return Promise.reject() })

the error emitted in the event would be undefined, when it should instead be Error: Rejected promise.

Usually this is fine, but since it gets normalized later it the channel error should match. Fixing this.

…el#hasSubscribers TracingChannel#hasSubscribers was added in Node 20.13/22 and is undefined on older supported versions, where `hasSubscribers !== false` is always true and forces tracing on every request. Check the sub-channels instead, which expose hasSubscribers on all supported versions.

Move the no-subscriber decision into handleRequest/handleError so the untraced path allocates no context object per request, matching the behavior on master. invokeWithTrace now receives the context object directly instead of a factory, since it only runs when tracing is active.

An error propagating through mounted sub-routers or forwarding error handlers was published on the error channel once per layer it passed through, so a single failure produced duplicate error events. Track the errors already reported for a request and publish each only at the layer where it originated.

A handler that throws 'route' or 'router' uses the same routing signals as next('route')/next('router') to skip the route or exit the router. Those were reaching the error channel because tracePromise reports any thrown value; catch them before tracePromise sees them so they aren't published as errors, matching how the signals are handled via next().

A handler that rejects or throws a falsy value (Promise.reject(), throw undefined) was reported on the error channel as that raw value, while the router forwards new Error('Rejected promise') to next(). Normalize once, before tracePromise reports it, so the channel and downstream handlers see the same error instance.

bjohansebas · 2026-07-15T17:16:02Z

+    const ret = requestChannel.tracePromise(function () {
+      // Catch thrown/rejected routing signals here so tracePromise doesn't
+      // report them as errors; real errors propagate and are reported as usual.
+      // A falsy rejection is normalized to the same error the router forwards to
+      // next(), so the error channel and downstream handlers see one instance.
+      let out
+      try {
+        out = handlePromise(exec(wrappedNext))
+      } catch (err) {
+        if (isRoutingSignal(err)) {
+          next(err)
+          return
+        }
+        throw err || new Error('Rejected promise')
+      }

-    // wait for returned promise
-    if (isPromise(ret)) {
-      if (!(ret instanceof Promise)) {
-        deprecate('handlers that are Promise-like are deprecated, use a native Promise instead')
+      if (out) {
+        return out.then(undefined, function (err) {
+          if (isRoutingSignal(err)) {
+            next(err)
+            return
+          }
+          throw err || new Error('Rejected promise')
+        })
      }
+    }, ctx)

+    if (ret) {
      ret.then(null, function (error) {
-        next(error || new Error('Rejected promise'))
+        // tracePromise already reported the rejection on this layer (with the
+        // normalized error); record it so outer layers don't report it again.
+        recordError(ctx.req, error)
+        next(error)
      })
    }
  } catch (err) {
+    // tracePromise already reported the sync throw on this layer; record it so
+    // outer layers don't report it again.
+    recordError(ctx.req, err)
    next(err)
  }


Okay, I think we can simplify this further while also fixing a few other cases where I found differences compared to master. I've described those cases in the comments, and you can take a look and decide whether you think this is the best approach.

Suggested change

const ret = requestChannel.tracePromise(function () {

// Catch thrown/rejected routing signals here so tracePromise doesn't

// report them as errors; real errors propagate and are reported as usual.

// A falsy rejection is normalized to the same error the router forwards to

// next(), so the error channel and downstream handlers see one instance.

let out

try {

out = handlePromise(exec(wrappedNext))

} catch (err) {

if (isRoutingSignal(err)) {

next(err)

return

}

throw err || new Error('Rejected promise')

}

// wait for returned promise

if (isPromise(ret)) {

if (!(ret instanceof Promise)) {

deprecate('handlers that are Promise-like are deprecated, use a native Promise instead')

if (out) {

return out.then(undefined, function (err) {

if (isRoutingSignal(err)) {

next(err)

return

}

throw err || new Error('Rejected promise')

})

}

}, ctx)

if (ret) {

ret.then(null, function (error) {

next(error || new Error('Rejected promise'))

// tracePromise already reported the rejection on this layer (with the

// normalized error); record it so outer layers don't report it again.

recordError(ctx.req, error)

next(error)

})

}

} catch (err) {

// tracePromise already reported the sync throw on this layer; record it so

// outer layers don't report it again.

recordError(ctx.req, err)

next(err)

}

requestChannel.tracePromise(function () {

let out

try {

out = handlePromise(exec(wrappedNext))

} catch (err) {

// forwarded verbatim: a falsy throw keeps routing, like the untraced path

wrappedNext(err)

return

}

if (out) {

return out.then(undefined, function (err) {

wrappedNext(err || new Error('Rejected promise'))

})

}

}, ctx)

For example, when a falsy value is thrown in synchronous mode, like in the following example:

dc.tracingChannel('express.router.request').subscribe(handlers) router.get('/falsy', function throwsFalsy(req, res) { throw undefined // eslint-disable-line no-throw-literal }) router.get('/falsy', function continues(req, res) { res.statusCode = 200 res.end('continued') }) request(server) .get('/falsy') .expect(200, 'continued', function (err) { if (err) return done(err) const errorEvents = events.filter(function (e) { return e.phase === 'error' }) assert.equal(errorEvents.length, 0, 'a falsy throw is treated as "no error" by the router — subscribing must not divert it to error handling') done() })

Without tracing enabled, the router doesn't treat this as an error and simply continues as normal. However, once tracing is enabled, it now automatically treats it as an error. It's also interesting that we don't currently have a test covering the normal behavior. It's definitely an edge case, but enabling tracing shouldn't change the router's behavior.

Could you add a test for this case

it('should continue routing after throwing a falsy value', function (done) { const router = new Router() const server = createServer(router) router.use(function handle (req, res, next) { throw undefined // eslint-disable-line no-throw-literal }) router.use(sawError) router.use(helloWorld) request(server) .get('/') .expect(200, 'hello, world', done) }) ``

Another case we have is when the same error is rethrown. It's technically valid—people do some crazy things 😄—but here's the scenario:

dc.tracingChannel('express.router.request').subscribe(handlers) router.get('/fail', function origin (req, res, next) { next(new Error('boom')) }) router.use(function rethrowing (err, req, res, next) { // eslint-disable-line no-unused-vars throw err }) router.use(function recover (err, req, res, next) { // eslint-disable-line no-unused-vars res.statusCode = 500 res.end(err.message) }) request(server) .get('/fail') .expect(500, 'boom', function (err) { if (err) return done(err) const errorEvents = events.filter(function (e) { return e.phase === 'error' }) assert.equal(errorEvents.length, 1, 'rethrowing the same error must not re-report it — throw and next(err) are equivalent to the router') assert.equal(errorEvents[0].ctx.layer.name, 'origin') done() })

In this case, it currently emits the error event twice. I don't think that makes sense—we shouldn't report the same error twice. From the router's perspective, throw err and next(err) are equivalent, so a single error should only produce a single error event.

It all depends on the user's coding style.

Yep that looks much better, I enumerated all cases again and ran what I just pushed against them, should be good now 👍

Thanks for double checking here!

Replace the repeated 'express.router.request' literal with a CHANNEL constant, and hoist the per-test byLayer/byName predicate into a single shared helper at the bottom of the file.

Send every handler outcome (return, throw, rejection) through wrappedNext instead of re-throwing into tracePromise's own error publishing. This puts signal filtering and error dedup in one place and keeps two behaviors in line with the untraced router: - a sync falsy throw is forwarded verbatim, so it keeps routing instead of being turned into an error - an error rethrown by an error handler is the same error, so it is reported once at its origin rather than twice Async rejections with a falsy reason are still normalized to the error the router forwards to next(), reported once.

Add a traced() helper for the router+server+subscribe setup, a byPhase() predicate to match the byLayer() one, and a shared recover error handler, replacing the copies repeated across the tracing tests.

logaretm added 3 commits April 15, 2026 08:17

refactor: reduce duplication in invokeWithTrace

858399c

Extract handlePromise and unify the traced/untraced paths into a single try/catch and .then handler.

fix: guard against missing dc.tracingChannel on older Node versions

9f1aea7

Copilot AI review requested due to automatic review settings April 15, 2026 12:45

Copilot started reviewing on behalf of logaretm April 15, 2026 12:45 View session

logaretm added a commit to getsentry/js-tracing-channels-proposals that referenced this pull request Apr 15, 2026

docs: update tracker and proposal with Express PR link

76adabf

Express TracingChannel PR opened: pillarjs/router#196

Copilot AI reviewed Apr 15, 2026

View reviewed changes

Comment thread lib/layer.js Outdated

Comment thread lib/layer.js Outdated

logaretm added 2 commits April 15, 2026 09:23

ref: use node: prefix

dea81ae

fix: use the top-level hasSubscribers flag

1f6bc25

Qard approved these changes Apr 20, 2026

View reviewed changes

test: pin down error event semantics for next(err) flows

1ad1b9c

logaretm force-pushed the tracing-channel branch from 30c87c5 to 1ad1b9c Compare April 20, 2026 16:50

Qard reviewed Apr 20, 2026

View reviewed changes

logaretm added 4 commits April 20, 2026 16:21

fix: always publish error events before calling next

28b3213

fix: refine error handling for control-flow sentinels in invokeWithTrace

90ed7e2

test: added case for router control flow error

758030e

test: assert handled flag on error events in both-layers error tests

9c9b4a7

bjohansebas requested review from efekrskl and krzysdz April 21, 2026 03:07

Qard approved these changes Apr 21, 2026

View reviewed changes

Flarna reviewed Apr 21, 2026

View reviewed changes

refactor: rename tracing channel to pillarjs.router.request

67c3851

Follows the Node.js TracingChannel naming guideline (dot-separated, module-scoped) and avoids the express-specific prefix since router is usable outside express.

bjohansebas reviewed Apr 26, 2026

View reviewed changes

docs: document pillarjs.router.request tracing channel

6aa0575

refactor: rename tracing channel to express.router.request

5e80078

logaretm mentioned this pull request Apr 28, 2026

TracingChannel Proposal for observability Automattic/mongoose#16105

Closed

2 tasks

sergical mentioned this pull request May 4, 2026

Observability through TracingChannels API remix-run/remix#11347

Open

logaretm mentioned this pull request May 11, 2026

Adopt TracingChannel for observability anthropics/anthropic-sdk-typescript#1036

Open

bjohansebas mentioned this pull request Jun 17, 2026

2026-06-17 Express Working Session expressjs/discussions#502

Closed

logaretm mentioned this pull request Jun 26, 2026

Observability through TracingChannels API honojs/hono#4842

Open

bjohansebas mentioned this pull request Jul 15, 2026

Use diagnostics_channel in layers #96

Closed

bjohansebas suggested changes Jul 15, 2026

View reviewed changes

logaretm added 6 commits July 15, 2026 00:40

docs: clarify error semantics on the request tracing channel

10a47bc

bjohansebas reviewed Jul 15, 2026

View reviewed changes

logaretm added 3 commits July 15, 2026 14:08

test: extract channel-name constant and shared byLayer helper

9aa666a

Replace the repeated 'express.router.request' literal with a CHANNEL constant, and hoist the per-test byLayer/byName predicate into a single shared helper at the bottom of the file.

test: hoist repeated setup and predicates into shared helpers

97da6d8

Add a traced() helper for the router+server+subscribe setup, a byPhase() predicate to match the byLayer() one, and a shared recover error handler, replacing the copies repeated across the tracing tests.

This was referenced Jul 15, 2026

feat: add diagnostic channels for request lifecycle expressjs/express#7171

Closed

Document req.route expressjs/expressjs.com#2450

Open

Uh oh!

Uh oh!

Conversation

logaretm commented Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context shape

Usage Example:

Is tracing channels experimental?

Related work

Caveats

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Qard left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logaretm Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Qard left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logaretm Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Qard left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logaretm Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

logaretm Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Flarna commented Apr 23, 2026

Uh oh!

logaretm commented Apr 23, 2026

Uh oh!

Qard commented Apr 26, 2026

Uh oh!

bjohansebas commented Apr 26, 2026

Uh oh!

bjohansebas left a comment

Choose a reason for hiding this comment

Uh oh!

logaretm commented Apr 27, 2026

Uh oh!

bjohansebas left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

logaretm commented Apr 15, 2026 •

edited

Loading

logaretm Apr 20, 2026 •

edited

Loading

logaretm Apr 20, 2026 •

edited

Loading

logaretm Apr 21, 2026 •

edited

Loading

logaretm Apr 27, 2026 •

edited

Loading

bjohansebas left a comment •

edited

Loading

logaretm Jul 15, 2026 •

edited

Loading