Reland "Replace log package with fully slog-based system"#8854
Draft
aarongable wants to merge 11 commits into
Draft
Reland "Replace log package with fully slog-based system"#8854aarongable wants to merge 11 commits into
aarongable wants to merge 11 commits into
Conversation
This reverts commit 7390cf7.
On a failed local CAA check, the "CAA check result" audit line attached the internal error under blog.Error's "error" key, which the deferred logger also uses for the client-visible problem, producing duplicate keys in one JSON record. Parsers keep only one of the two values. Key the internal error as internalErr, matching the equivalent code in DoDCV. This PR was generated as part of an audit of #8606 using Claude Fable 5.
The slog migration (#8606) dropped RequestEvent.Error from the request completion log: web.SendError still recorded the client-visible problem details on the event, but logEvent() never emitted them, so failed ACME requests logged only their status code. Emit the field under the key "problem" ("error" is reserved for the blog.Error helper). This PR was generated as part of an audit of #8606 using Claude Fable 5.
Before #8606, the certificateRevocationEvent struct carried the requested reason code from the moment it was created, so every "Revocation request" audit line included it, even on error paths. The migration attached it to the context only after the cross-account ownership check, so early failures (e.g. GetSerialMetadata errors) produced audit lines with no reason. Log the reason from the local variable in the deferred call so it reflects the requested (or overridden) value no matter where the function exits. This PR was generated as part of an audit of #8606 using Claude Fable 5.
The crl-updater attaches issuerNameID to all its log lines (added during #8606 review), but the storer's "CRL uploaded" line carried only the issuer CN. Since the S3 object key is {nameID}/{shardIdx}.crl, tying an upload log line to its object required an out-of-band CN to NameID mapping. Log the NameID too. This PR was generated as part of an audit of #8606 using Claude Fable 5.
…8848) The audit and plain sub-handlers each hold only their own internal lock, so the shared underlying writer receives concurrent whole-line Write calls from both. Every current writer tolerates this (os.File serializes concurrent Write calls internally, and syslog.Writer and the test mock hold their own locks), but the requirement is invisible at the io.Writer interface. Document it at the point where a future writer (for example a bufio.Writer added while moving to stdout-only logging) would be inserted. This PR was generated as part of an audit of #8606 using Claude Fable 5.
docs/logging.md claimed all log lines carry datacenter/host/program/pid attributes. Those were deliberately removed from prod during #8606 review (collectors add them), with only prog retained in test builds. blog.Config's StdoutLevel comment still described a stdout/stderr split that no longer exists. This PR was generated as part of an audit of #8606 using Claude Fable 5.
blog.Serial documents that its argument should be the hex-encoded form, and every other call site uses core.SerialToString. This one logged the big.Int decimal form, which matches nothing else in the system when searching or joining on serial. This PR was generated as part of an audit of #8606 using Claude Fable 5.
Error, AuditError, and AuditInfo appended internal attrs (error, audit) directly to the caller's variadic slice. When a caller passes a slice with spare capacity, that append writes into the caller's backing array, leaking a stray attr into any later use of the slice. Clip the slice first so the append always allocates. (ContextWith was given the equivalent fix during #8606 review, but these methods were missed.) This PR was generated as part of an audit of #8606 using Claude Fable 5.
The dry-run UpdateIncident log recorded zero values (1970 timestamps, enabled=false) for fields the request leaves unset. A real UpdateIncident only applies non-empty fields, so the dry-run record misrepresented what a real run would do. Log only the fields present in the request, so "absent" always means "not changed". This PR was generated as part of an audit of #8606 using Claude Fable 5.
mcpherrinm
requested changes
Jul 7, 2026
mcpherrinm
left a comment
mcpherrinm
left a comment
Contributor
There was a problem hiding this comment.
Using "Request changes" while we evaluate log compatibility
aarongable
commented
Jul 7, 2026
Contributor
Author
There was a problem hiding this comment.
Do not resolve this comment until given approval by SRE -- this comment blocks merging until resolved.
Comment on lines
+1041
to
+1046
| // Log the authzs used to validate this order. We log this now to reflect the | ||
| // fact that we *intended* to use these authzs to issue a cert, even if that | ||
| // issuance ends up failing. And even if that issuance does fail, this func | ||
| // can't exit without logging the attempt, so these authz logs will always | ||
| // correspond to (and carry the same `id` field as) a "Certificate request | ||
| // complete" line logged below. |
Contributor
There was a problem hiding this comment.
Would it be possible to keep the practice of logging these in the same logline as "Certificate request - successful"?
Contributor
Author
There was a problem hiding this comment.
Definitely possible, but these were moved out of that monolithic log line at the request of SRE to prevent any single log line from getting too large (e.g. when there are 100 authzs to log for a single certificate issuance). Which of those is a higher priority concern?
(It also raises some questions about how they should be formatted in that log line. Although JSON has the concept of arrays, slog doesn't: everything is keyed. So we'd end up doing something like "authzs": {"1": {...}, "2": {...}, etc}. Kinda ugly but maybe that's okay?)
Contributor
There was a problem hiding this comment.
I'll confirm with SREs but I think correlating the information in a single logline is more important than the large loglines concern in this case.
Maybe instead of "authzs": {"1": {...}, "2": {...}, etc}, could there be a authzLog or similar struct that gets logged as slog type any, keeping the existing structure? Then just let encoding/json do the marshaling.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This reverts PR #8853, which was merged as commit 4f9cc84.
This relands PR #8606, which was merged as commit abfceb5, plus the following additional fixes:
Fixes #8557
Warning
DO NOT MERGE until all twelve PRs listed above have been merged into this PR's branch.