Experimental tracing logging for command()#520
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds experimental tracing/logging instrumentation to the command execution flow to help diagnose stream handling and timing issues. The changes introduce detailed trace logging at key points during command execution and stream draining operations.
Key changes:
- Enhanced
drainStreamfunction with optional logging parameters to trace stream drain lifecycle events - Added comprehensive logging throughout the command execution pipeline including timing metrics and stream state information
- Modified parameter passing to ensure
query_idis propagated consistently through the execution flow
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
packages/client-node/src/connection/stream.ts |
Added logging to track stream drain operations including chunk counts, bytes received, and duration metrics |
packages/client-node/src/connection/node_base_connection.ts |
Instrumented command execution flow with trace logging for timing, stream states, and error conditions; adjusted query_id handling |
Comments suppressed due to low confidence (1)
packages/client-node/src/connection/stream.ts:99
- The event name in
removeListenershould be 'close' not 'onClose'. This typo means the close event listener will never be properly removed, potentially causing a memory leak in long-running applications.
function removeListeners() {
stream.removeListener('data', dropData)
stream.removeListener('end', onEnd)
stream.removeListener('error', onError)
stream.removeListener('onClose', onClose)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
25ae82e to
cbb468b
Compare
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
let's see if it goes anywhere far
|
I've pushed changes that:
If the verbosity flag lifts-off we should address the testing story by running tests with and without verbosity to make sure switching in production is safe. Think of this as performance vs. debug builds in other platforms. |
|
After a discussion we're moving with adding a log level as an argument instead of verbosity that will do the same but keep the entity count lower. |
921afc3 to
f8b44c0
Compare
|
Ok, |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@copilot check the code in this branch for cases where a call to logger ( |
|
@peter-leonov-ch I've opened a new pull request, #565, to work on those changes. Once the pull request is ready, I'll request review from you. |
| }, | ||
| database: config.database ?? 'default', | ||
| log_writer: new LogWriter(logger, 'Connection', config.log?.level), | ||
| log_level: config.log?.level ?? ClickHouseLogLevel.OFF, |
There was a problem hiding this comment.
IMO, default should be INFO
There was a problem hiding this comment.
Fair point. OFF seems to be the default for the default LogWriter:
Do you want to change it and converge both to INFO?
There was a problem hiding this comment.
The current default is OFF
And also warns about suppressed warnings:
The current default log level is OFF. This means that when users create a client with no arguments, all logging is disabled - including warnings about deprecated configuration options.
Maybe we change the default to WARN instead and make sure the log levels in to code use WARN for noteworthy bits?
With WARN as default, I need to check what logs a successful ping() call generates. Looking at the other integration test, a successful ping produces a debug log, which would be suppressed at WARN level.
Looks like Copilot can draft something here for "free" 🙂
There was a problem hiding this comment.
Maybe we change the default to WARN instead and make sure the log levels in to code use WARN for noteworthy bits?
do we have any logs with info level?
There was a problem hiding this comment.
A quick grep shoes we do not.
Waiting on: * #520 ## Summary * adding tests to cover for the tricky connection related situations * augment logs with context required for debugging ## Checklist Delete items not relevant to your PR: - [x] Unit and integration tests covering the common scenarios were added - [x] A human-readable description of the changes was provided to include in CHANGELOG --------- Co-authored-by: Copilot <[email protected]>
Summary
In this PR:
thisproperties for keeping context and more theparamsthat brings us closer to thread/async safe Go-like context monadChecklist