Skip to content

(2.11.x) [log] Add TraceHeaders option #6638

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

Merged
merged 1 commit into from
Mar 20, 2025
Merged

Conversation

bruth
Copy link
Member

@bruth bruth commented Mar 11, 2025

When true, trace logs will no longer emit the payload of the message, only the headers if these are present.

An additional change, is not emitting the MSG_PAYLOAD log line if the payload is empty.

@derekcollison derekcollison requested a review from kozlovic March 11, 2025 11:35
@bruth bruth marked this pull request as ready for review March 11, 2025 11:42
@bruth bruth requested a review from a team as a code owner March 11, 2025 11:42
@ripienaar
Copy link
Contributor

I like this, but defer for 2.11.x?

@bruth
Copy link
Member Author

bruth commented Mar 11, 2025

@ripienaar agreed. will update the title to indicate

@bruth bruth changed the title [log] Add TraceHeaders option (2.11.x) [log] Add TraceHeaders option Mar 11, 2025
@alexbozhenko
Copy link
Contributor

@bruth Would it be possible to include a reproducible test plan in the PR description? It might be clear to experienced reviewers, but for those of us still ramping up, having explicit commands and expected output would help us understand the behavior change. It would also make it easier to communicate updates to customers and save us some cycles. Thanks!

@bruth
Copy link
Member Author

bruth commented Mar 11, 2025

Thanks @kozlovic, will review shortly! Yes @alexbozhenko I will add a test for this, so the expected behavior is clear.

@bruth bruth force-pushed the trace-log-headers branch from 752259f to 783929d Compare March 12, 2025 00:36
@bruth
Copy link
Member Author

bruth commented Mar 12, 2025

@kozlovic I went with the second approach you suggested. I am going to add a test to exercise this.

@@ -1917,9 +1917,9 @@ func (c *client) traceMsg(msg []byte) {

if maxTrace > 0 && l > maxTrace {
tm := fmt.Sprintf("%q", msg[:maxTrace])
c.Tracef("<<- MSG_PAYLOAD: [\"%s...\"]", tm[1:maxTrace+1])
c.Tracef("<<- MSG_PAYLOAD: [\"%s...\"]", tm[1:len(tm)-1])
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed this since when converting to the quoted form, \r\n is escaped and thus four characters.

Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit about use of "" instead of _EMPTY_, but otherwise LGTM.

Desc: "payload only",
Msg: []byte(`test\r\n`),
Hdr: 0,
Wanted: "",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Derek would say to replace "" with _EMPTY (applies to all in this test)

@wallyqs
Copy link
Member

wallyqs commented Mar 13, 2025

It is going to be more helpful for investigations if we trace the headers when they are delivered as well with an option, that is the current limitation of tracing (since both payloads and headers are not shown on the receiving side).

[42994] 2025/03/13 10:32:32.461243 [TRC] 127.0.0.1:52590 - cid:6 - <<- [SUB _INBOX.Es5igIqrhJdEt9YeaqhPSM.GX7gwt9F  1]
[42994] 2025/03/13 10:32:32.461259 [TRC] 127.0.0.1:52590 - cid:6 - <<- [HPUB foo _INBOX.Es5igIqrhJdEt9YeaqhPSM.GX7gwt9F 22 26]
[42994] 2025/03/13 10:32:32.461272 [TRC] 127.0.0.1:52590 - cid:6 - <<- MSG_PAYLOAD: ["NATS/1.0\r\nfoo: bar\r\n\r\nasdf"]
[42994] 2025/03/13 10:32:32.461289 [TRC] 127.0.0.1:52586 - cid:5 - ->> [HMSG foo 1 _INBOX.Es5igIqrhJdEt9YeaqhPSM.GX7gwt9F 22 26]

@bruth
Copy link
Member Author

bruth commented Mar 13, 2025

It is going to be more helpful for investigations if we trace the headers when they are delivered as well with an option

I am not opposed, but to be clear, this is net new? We can do this in a follow-up PR.

Edit: How does this overlap with the debug message tracing functionality?

Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@neilalexander
Copy link
Member

Please rebase on top of latest main and will queue up for merge, thanks!

@bruth bruth force-pushed the trace-log-headers branch 2 times, most recently from 6aca199 to 804e81b Compare March 20, 2025 01:05
When true, trace logs will no longer emit the payload
of the message, only the headers if these are present.

An additional change, is not emitting the MSG_PAYLOAD
log line if the payload is empty.

Signed-off-by: Byron Ruth <[email protected]>
@bruth bruth force-pushed the trace-log-headers branch from 804e81b to 4799ca8 Compare March 20, 2025 11:33
@neilalexander neilalexander merged commit d0ce4c4 into main Mar 20, 2025
5 checks passed
@neilalexander neilalexander deleted the trace-log-headers branch March 20, 2025 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants