fix(intelligence): keep the escalation streak out of the log body - #930
fix(intelligence): keep the escalation streak out of the log body#930adityaharishch wants to merge 1 commit into
Conversation
`pre-main` is red: `log_hygiene::no_user_data_interpolated_into_a_log_body`
fails on
"provider unreachable on {streak} consecutive attempts - escalating to a notice"
The body is the one field `telemetry_spool::redact` cannot filter - attributes
are dropped unless allowlisted, but the body always ships verbatim to central
OpenObserve - so anything interpolated there egresses whether or not it should.
`streak` was ALREADY a structured field on this same call, so the body was
only duplicating it and nothing is lost by dropping it. Added `needed` too, so
the pair still reads as "n of m" without either number touching the body. The
count survives the ship leg as a bare number via `redact::is_bare_number`.
Neither PR that produced this was wrong on its own, and both were green:
- the message came from 4a0a2fc, on pre-main since August
- the guard that rejects it came from #916 (b4f33de)
#916's branch predated the message, so its new guard never scanned that line;
the collision only exists in the merge. This is the second instance today of
"green individually, red combined" - #923 was the other - and neither is
visible until after the merge lands on pre-main.
|
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: Organization UI Review profile: ASSERTIVE Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Superseded by #933, which landed the same fix independently while this was open: a static WARN body with Merging The defect is closed either way, and |
1 participant
pre-mainis redlog_hygiene::tests::no_user_data_interpolated_into_a_log_bodyfails onsrc/intelligence/providers/mod.rs:196:The message body is the one field
telemetry_spool::redactcannot filter - attributes are dropped unless allowlisted, but the body always ships verbatim to central OpenObserve. So anything interpolated there egresses regardless of whether it should.The fix is subtraction
streakwas already a structured field on the same call, so the body was only duplicating it. Removing it from the body loses nothing. I addedneededalongside it so the pair still reads as "n of m" without either number touching the body.The count still reaches OpenObserve: as a
u32it arrives as aStringValue(tracing-opentelemetry 0.28 has norecord_u64, so it falls through torecord_debug), andredact::is_bare_numberkeeps it because the whole value parses as a number.Why CI was green on both PRs and red once merged
4a0a2fc4, onpre-mainsince Augustb4f33de7#916's branch predated the message, so its new guard never scanned that line. The violation exists only in the merge, which is the first place the two meet.
This is the second "green individually, red combined" today - #923 was the other, and it merged with no Rust CI at all because it was based on a feature branch. Neither is visible until after the merge lands on
pre-main, which is also the moment it blocks a release. Worth considering a required merge-queue or an up-to-date-branch check, but that is a separate change and not this PR.Gate
cargo fmt --all --check,cargo clippy --workspace --all-targets -D warnings,cargo test --workspace(27 binaries green), plus the full pre-push suite.Context
This is blocking the staging release cut for
pre-main. Once this lands I will verifypre-mainis green and cutv1.91.0-staging.7.