Repository navigation
Add diagnostics_channel TracingChannel support - #24
zhanglongtu wants to merge 7 commits into
Conversation
Enables instrumentation libraries (OpenTelemetry, etc.) to subscribe to structured events without monkey-patching. Uses TracingChannel for async context propagation and plain channels for simple events. Channels: - pg:query (TracingChannel) — query lifecycle with result enrichment - pg:connection (TracingChannel) — client connect lifecycle - pg:pool:connect (TracingChannel) — pool checkout lifecycle - pg:pool:release (plain) — client released back to pool - pg:pool:remove (plain) — client removed from pool All instrumentation is guarded by hasSubscribers for zero overhead when unused. Gracefully degrades to no-ops on Node < 19.9 or non-Node environments. Closes #3619 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
TracingChannel is not available on Node 18 LTS. Skip the tracing-dependent tests gracefully instead of failing. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Node 18 backported TracingChannel but without the aggregated `hasSubscribers` getter (it returns `undefined` instead of a boolean). Raw truthiness checks treat `undefined` as "no subscribers" which silently disables tracing on Node 18. Replace all `channel.hasSubscribers` guards with `shouldTrace(channel)` which checks `hasSubscribers !== false` — treating `undefined` (Node 18) as "might have subscribers, trace unconditionally" and `false` (Node 20+) as "definitely no subscribers, skip". Also removes the now-unnecessary test skip logic since TracingChannel does exist on Node 18. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Node 18 backported TracingChannel but with a buggy implementation — unsubscribing and resubscribing to the same channel crashes internally (`_subscribers` becomes undefined). Node 16 has no TracingChannel at all. Gate tests on `hasStableTracingChannel` which checks both that `dc.tracingChannel` exists AND that the aggregated `hasSubscribers` getter returns a boolean (only true on Node 19.9+/20.5+). TracingChannel tests: skipped on Node 16/18, run on Node 20+ Plain channel tests (release/remove): run on all versions Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…omise type tracePromise wraps the result in a native Promise, which breaks clients configured with a custom Promise implementation (e.g. bluebird). Switch to traceCallback inside the user's this._Promise constructor so the returned promise type is always correct. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
There was a problem hiding this comment.
🟡 Changes recommended
Critical packaging and callback-tracing issues remain unresolved.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Adds optional diagnostics_channel tracing for pg queries/connections and pg-pool lifecycle events.
Changes:
- Adds tracing and diagnostic channels.
- Instruments client and pool lifecycle operations.
- Adds diagnostics unit tests.
File summaries
| File | Summary |
|---|---|
packages/pg/test/unit/client/diagnostics-tests.js |
Adds client diagnostics tests. |
packages/pg/lib/diagnostics.js |
Defines client tracing channels; builtin-module loading needs correction. |
packages/pg/lib/client.js |
Instruments connections and queries; callback tracing and native-client coverage require changes. |
packages/pg-pool/test/diagnostics.js |
Adds pool diagnostics tests. |
packages/pg-pool/index.js |
Publishes pool lifecycle events; the diagnostics module must be included in the package allowlist. |
packages/pg-pool/diagnostics.js |
Defines pool channels; builtin-module loading needs correction. |
Review details
Suppressed comments (4)
packages/pg-pool/diagnostics.js:33
- On Node 18 the comment above says the aggregate
hasSubscribersvalue isundefined; with!== false, this returns true even when every underlying tracing channel has no subscribers. Each pool connection acquisition then still goes throughtraceCallback, so the claimed no-subscriber zero-overhead path is not true on a supported runtime; check the component channels before tracing.
function shouldTrace(channel) {
return channel.hasSubscribers !== false
}
packages/pg-pool/index.js:223
traceCallbackexpectscontextimmediately after the function, but this passes0first. As a result pool acquisition callbacks are not wrapped correctly when tracing is enabled, preventing the caller's callback/promise from completing and making thepg:pool:connectlifecycle unusable. Passcontextas the second argument.
0,
context,
packages/pg/lib/client.js:12
- The new channels are wired only into the pure-JavaScript
Client;pg.nativeandNODE_PG_FORCE_NATIVEuselib/native/client.js, whose connect/query paths never publish these channels. Instrumentation subscribing to the documentedpg:queryandpg:connectionchannels will therefore silently miss supported native clients; add equivalent hooks or explicitly scope the API to the JS client.
const { queryChannel, connectionChannel, shouldTrace } = require('./diagnostics')
packages/pg/lib/diagnostics.js:29
- On Node 18 the comment above says the aggregate
hasSubscribersvalue isundefined; with!== false, this returns true even when every underlying tracing channel has no subscribers. Each query/connect then still goes throughtraceCallback, so the claimed no-subscriber zero-overhead path is not true on a supported runtime; check the component channels before tracing.
function shouldTrace(channel) {
return channel.hasSubscribers !== false
}
- Files reviewed: 6/6 changed files
- Comments generated: 5
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| @@ -1,5 +1,6 @@ | |||
| 'use strict' | |||
| const EventEmitter = require('events').EventEmitter | |||
| const { poolConnectChannel, poolReleaseChannel, poolRemoveChannel, shouldTrace } = require('./diagnostics') | |||
| const context = { | ||
| connection: { database: this.database, host: this.host, port: this.port, user: this.user, ssl: !!this.ssl }, | ||
| } | ||
| connectionChannel.traceCallback((tracedCb) => this._connect(tracedCb), 0, context, null, callback) |
| if (typeof process.getBuiltInModule === 'function') { | ||
| dc = process.getBuiltInModule('diagnostics_channel') |
| if (shouldTrace(queryChannel) && query.callback) { | ||
| const context = { | ||
| query: { text: query.text, name: query.name, rowMode: query._rowMode }, | ||
| client: { | ||
| database: this.database, |
| if (typeof process.getBuiltInModule === 'function') { | ||
| dc = process.getBuiltInModule('diagnostics_channel') |
This PR introduces tracing channels support to
pg-poolandpgquerying methods as discussed in #3619I haven't yet run a benchmark, but without active tracing or subscribers the overhead is non-existent so existing users shouldn't be affected. The overhead would come from the consumers of the diag channels published here which is done anyways via monkey patching.
I added the following channels:
pg:querypgpg:connectionpgpg:pool:connectpg-poolpg:pool:releasepg-poolpg:pool:removepg-poolI understand there may be hesitation given that AI tooling was used in the implementation. To be clear, this isn't a drive-by contribution. I designed the channel layout, wrote the proposal document, and iterated through multiple rounds to handle real edge cases (Node 18 compat, preserving custom Promise types, hasSubscribers guards). The AI assisted with the code, but the approach and decisions are mine.
Usage
Instrumentations will only need to subscribe to tracing channels to create traces, logs or metrics:
This is part of a broader initiative to bring TracingChannel support to the most widely used Node.js database and cache libraries. The same pattern has already been merged and shipped in:
I have been directly involved in those prior implementations and I'm happy to own this through to release, address any feedback, and provide whatever support is needed. Would love to hear your thoughts.
Supersedes #3624.