-
Notifications
You must be signed in to change notification settings - Fork 245
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
DRIVERS-1677, DRIVERS-1673: Add general logging specification and command logging #1303
Conversation
0fb43c7
to
1dcb013
Compare
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
1dcb013
to
23e511d
Compare
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
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.
Lots of comments, but this looks fantastic. Nice work.
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/command-logging-and-monitoring.rst
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/tests/logging/unified/operation-id.yml
Outdated
Show resolved
Hide resolved
source/command-logging-and-monitoring/tests/logging/unified/operation-id.yml
Outdated
Show resolved
Hide resolved
has a redacted failure, e.g. an empty string or object. | ||
The exact form of those assertions will vary based on the driver's chosen | ||
representations for failures and redacted failures in log messages. | ||
in its attached data. Then this field is set to ``false``, the test runner |
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.
Then -> When
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.
thanks; ended up deleting this per above thread about using a single boolean
I'm confused about the "Check if all JSON test files are up-to-date" failure. it seems to be complaining about a CMAP test I haven't touched here, and the "diff" is a line that looks identical before and after. it doesn't seem relevant
edit: ah it's a whitespace change. I'll make a small separate PR to correct that so we can get a complete CI run on the new tests. I wonder why this only showed up now... the js-yaml version hasn't changed |
|
||
- ``failureIsRedacted``: Optional boolean. This field SHOULD only be specified | ||
when ``data`` contains ``{ failure: { $$exists: true }}``; the test runner | ||
MUST report an error if this is not the case. |
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 didn't expect this would require a subsequent assertion on the contents of data
field in the test file. Rather, the mere presence of failureIsRedacted
would require a driver to assert that there is some failure to inspect in the first place. In other words, a test could use failureIsRedacted
on its own with no meaningful data
assertion and trust the assertion would fail outright if the log data omitted a failure altogether.
I imagine there might also be cases where data.failure
could be something other than { $$exists: true }
(perhaps a $$type
assertion or something more specific.
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.
ah, I misunderstood your comment above. and good point re: other assertions on failure
being possible.
I updated the language here to just say
This field SHOULD only be specified when the log message data is expected to contain a
failure
value.
#1316 bumped the unified format schema version; just pushed another few commits to reflect this so that the logging changes are added via schema version 1.13. |
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.
LGTM!!!!
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.
LGTM (2 minor comments)
|
||
Unacknowledged/Acknowledged Writes | ||
---------------------------------- | ||
|
||
Unacknowledged writes must provide a ``CommandSucceededEvent`` with a ``{ ok: 1 }`` reply. | ||
Unacknowledged writes must provide a ``CommandSucceededEvent`` and a "command succeeded" log message with a ``{ ok: 1 }`` reply . |
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.
nit: redundant space in reply .
?
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.
removed. thanks!
* - command | ||
- String | ||
- Relaxed extJSON representation of the command. This document MUST be truncated appropriately according to rules defined in the | ||
`logging specification <../logging/logging.rst>`_, and MUST be replaced with an empty document "{ }" if the command is considered sensitive. |
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.
For your consideration, you could add a link to the truncation section #truncation-of-large-documents.
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.
good thought to add a link. that section covers truncation rationale, but I am going to add one to the section on truncation rules: Configurable Max Document Length.
This is the first in a series of PRs for the logging spec.
This PR adds:
Future PRs will add logging and tests for CMAP, SDAM, and server selection.