You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has been mentioned several times, both in meetings and other issues, to provide support for diagnostic channels, which seems to be something that wants to be integrated into Express no matter what. I am posting this in the issue in case anyone is interested in working on it.
The integration should also be done in the router module.
+1 as it could be a useful way to share diagnostic info throughout the ecosystem.
I'm interested in working on this. That said, before getting too far it might be worth discussing the desired direction for both logging and diagnostics overall.
I know @wesleytoddhas talked about integrating pino as a logger a few times and while these tools do different things to solve different problems, I imagine they could end up working together. As they are related, I think it would be good to align on the strategy for each of them for v6.
I am hoping to consolidate this work into the Performance WG since mostly this will be used to observe performance (while recognizing it serves other o11y purposes).
Additionally @simon-id, @Qard, @timfish, and @AbhiPrasad have all either worked in this area or mentioned interest in this work. I will keep this open until we have a better place to discuss, but want to point folks to this Perf WG proposal so we can get everyone involved in a productive way with that.
Reacted by Abhijeet Prasad, Dustin Popp, Stephen Belanger, Sebastian Beltran, simon-id and Ilyas Shabi
Reacted by Abhijeet Prasad, Tim Fish, Stephen Belanger and Sebastian Beltran
I can implement Node.js diagnostic channels support in Express. I understand this involves instrumenting key lifecycle events like request/response cycles, middleware execution, and route matching. I'll add the diagnostics_channel integration points while maintaining backward compatibility and providing clear documentation for monitoring use cases.
@efekrskl@wesleytodd I have been contributing tracing channels support across a few libraries (redis, pg, mysql2, nitro) recently, so I'm happy to help adopt this into express as it feels like a must have for an instrumentation future without monkey patching.
I noticed there are already a few PRs/issues/discussions sprinkled here and there for this. Any chance to resolve those to see what's missing or perhaps do we need a place to spec this out first properly? like how many channels do we need, what context information to pass, etc...
A first implementation should probably be a small diagnostics contract PR, not a logging abstraction.
Concrete slice:
Start in pillarjs/router, because route/layer matching lives there and Express can consume it without duplicating matching logic.
Define only lifecycle channels for routing: router:route:match, router:route:start, router:route:end, router:route:error (or namespaced under express:router:* if maintainers prefer a public namespace).
Use stable payload fields: { req, route, layer, params } for match/start/end and { req, route, layer, params, error } for error. Avoid response body, timing policy, or logger integration in the first PR.
Gate publishes through the normal diagnostics_channel subscriber checks so the no-subscriber path stays close to current performance.
Add Express integration tests that subscribe to the router channels during a request and verify ordering for success and error middleware.
That gives the Perf WG a concrete observable surface to iterate on without coupling the first change to a logger or tracing vendor.
Activity
dpopp07 commentedon Feb 20, 2025
+1 as it could be a useful way to share diagnostic info throughout the ecosystem.
I'm interested in working on this. That said, before getting too far it might be worth discussing the desired direction for both logging and diagnostics overall.
I know @wesleytodd has talked about integrating
pinoas a logger a few times and while these tools do different things to solve different problems, I imagine they could end up working together. As they are related, I think it would be good to align on the strategy for each of them for v6.I opened expressjs/discussions#341 to discuss.
wesleytodd commentedon Mar 5, 2025
pillarjs/router#96
I am hoping to consolidate this work into the Performance WG since mostly this will be used to observe performance (while recognizing it serves other o11y purposes).
Additionally @simon-id, @Qard, @timfish, and @AbhiPrasad have all either worked in this area or mentioned interest in this work. I will keep this open until we have a better place to discuss, but want to point folks to this Perf WG proposal so we can get everyone involved in a productive way with that.
ahmed-abdalkder commentedon Jun 24, 2025
Hi! I'm interested in working on this issue. Could you please assign it to me?
wesleytodd commentedon Jun 24, 2025
@ahmed-abdalkder, we typically do not assign issues like this. Please feel free to open PRs and issues in the relevant areas.
dohrisalim commentedon Nov 9, 2025
I can implement Node.js diagnostic channels support in Express. I understand this involves instrumenting key lifecycle events like request/response cycles, middleware execution, and route matching. I'll add the diagnostics_channel integration points while maintaining backward compatibility and providing clear documentation for monitoring use cases.
efekrskl commentedon Nov 10, 2025
Hi @dohrisalim, as Wesley already mentioned, feel free to open a PR with your implementation.
feat: add diagnostics_channel support
feat: add support for diagnostic channels
logaretm commentedon Mar 16, 2026
@efekrskl @wesleytodd I have been contributing tracing channels support across a few libraries (redis, pg, mysql2, nitro) recently, so I'm happy to help adopt this into express as it feels like a must have for an instrumentation future without monkey patching.
I noticed there are already a few PRs/issues/discussions sprinkled here and there for this. Any chance to resolve those to see what's missing or perhaps do we need a place to spec this out first properly? like how many channels do we need, what context information to pass, etc...
feat: add diagnostic channels for request lifecycle
feat: add TracingChannel support for express:request
feat: add TracingChannel support for express:request
MakenRosa commentedon Jun 20, 2026
A first implementation should probably be a small diagnostics contract PR, not a logging abstraction.
Concrete slice:
pillarjs/router, because route/layer matching lives there and Express can consume it without duplicating matching logic.router:route:match,router:route:start,router:route:end,router:route:error(or namespaced underexpress:router:*if maintainers prefer a public namespace).{ req, route, layer, params }for match/start/end and{ req, route, layer, params, error }for error. Avoid response body, timing policy, or logger integration in the first PR.diagnostics_channelsubscriber checks so the no-subscriber path stays close to current performance.That gives the Perf WG a concrete observable surface to iterate on without coupling the first change to a logger or tracing vendor.
LeonxLJX commentedon Sep 1, 2026
I'd like to take this one (
Support diagnostic channels). I'll look into the root cause and follow up with a PR. (claiming via @LeonxLJX)LeonxLJX commentedon Sep 1, 2026
I'd like to take this one (
Support diagnostic channels). I'll look into the root cause and follow up with a PR. (claiming via @LeonxLJX)