Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(NODE-4686): Add log messages to CLAM #3955
feat(NODE-4686): Add log messages to CLAM #3955
Changes from 23 commits
6d32c32
5f5d77e
209ba27
3bee17a
fcfc98b
422c6a9
c360ec2
054094f
0d8d051
383f890
7033dc8
1d70579
0ae8792
e92849d
9776ec9
3332f94
cacaed2
fa223cf
299e8a1
1181991
8f6c860
dc93151
cbb5df6
9ace7a0
e9d4f8d
7892601
3c18428
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the expected behavior with command logging when we re-authenticate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reauthentication will send commands we don't want to log I think. We may either need to
established
to false when reauthenticating and then set it back to true after a successful reauthenticationThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, pinged you on slack for more info on reauth
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I didn't notice this earlier ( I didn't actually check ) but instead of modifying
established
when we reauthenticate, could we just check thecontext.reauthenticating
field?one idea is a getter on the connection class (or we could just inline it):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it more accurate to edit established as well, though? Since during authentication, the connection is not established.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understood established to mean that the connection had been established, not that it was "ready"/currently established. What I would like to avoid is duplicate data that might get out of sync. If established=false can also represent a connection reauthenticating, then it's possible for us to end up in a scenario context.reauthenticating=true with established=false (or vice versa) - which is a poorly defined state for the driver.
One way to avoid this is to define established as whether or not the connection was initially established and rely on context.reauthenticating (my suggestion).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds good. I've removed the extra auth changes to
conn.established
and am usingthis.authContext?.authenticating
in the new gettershouldEmitAndLogCommand
instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting idea - I see it's used in TypedEventEmitter to know which logging component to use.
Will there ever be a case where
emitAndLogCommand
will be used to log for a component that is notMongoLoggableComponent.COMMAND
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, there won't. The extra
this.component
check should ensure that anemitAndLog
or variant function (emitAndLogCommand, emitAndLogHeartbeat
) is not called from any class for which the logging component is not defined already.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can add in an extra check such as:
this.component === MongoLoggableComponent.COMMAND
, remove thethis.component
check foremitAndLogCommand
, or keep it the same. What do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's strange to me that we have a dedicated method for logging commands, but to use it we also need to set the component on the class. I would expect that either:
emitAndLogCommand()
, and not thecomponent
property.emitAndLog()
method that uses thecomponent
property and no specialized methods on the TypedEventEmitterIf we want to prevent the emitAndLog functions from being called, maybe we could use inheritance for this? that way we could only define the log methods where they can be used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true. For the sake of this PR, I'll just hardcode in the component in
emitAndLogCommand
asMongoLoggableComponent.COMMAND.
Since I realizeemitAndLogCommand
already implies that the command component is being utilized.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-blocking and definitely only tangentially related: the
.slice()
call below can end up truncatingstrToTruncate
in the middle of a character. That won't happen a lot if the string mostly just contains ASCII data, but since this is a very low-level generic utility, it might be worth accounting for that case (e.g.if (strToTruncate.length > maxDocumentLength && strToTruncate.charCodeAt(maxDocumentLength-1) !== strToTruncate.codePointAt(maxDocumentLength-1)) maxDocumentLength--;
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something we will solve / take a further look at in NODE-5839.