Repository navigation
Say that queue drops are silent and how the tags block skips lines - #20
Merged
dmccoystephenson merged 1 commit intoOct 18, 2026
Merged
Conversation
The "Bounded" row sat under "Drops are logged at FINE", but a report dropped by a full queue goes through DiscardPolicy and is never logged. The row now says so, and the flood test attaches a logger and checks nothing is logged. The server-wide tags bullets now also say that a line indented differently from the block's first entry is skipped, and that an enabled: line inside the block is a tag rather than the switch. Both were already in parseServerWideConfig's Javadoc and its tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
Self-review rubric (anchor: CI run 39114275033 on the PR head,
Repo-specific:
Observations:
This review was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener). drafted by Claude on behalf of Daniel Stephenson |
dmccoystephenson
deleted the
feature/readme-silent-queue-drops-and-tag-block-rules
branch
October 18, 2026 09:11
1 of 2 tasks
dmccoystephenson
added a commit
that referenced
this pull request
Oct 19, 2026
…adoc (#21) * Say what the logger hears and that queue drops are silent, in the Javadoc Builder.logger said "Where dropped reports are mentioned", but a report dropped by the full queue goes through DiscardPolicy and is never logged, as the README's "Bounded" row has said since #20. The logger also hears more than drops: build() logs a server-wide config or install ID file it could not read or write. The Javadoc now lists what is logged and what is not. The class Javadoc's "It is bounded" bullet now says the drop is silent, matching the same README row. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Rewrap the bounded bullet in the class Javadoc Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
dmccoystephenson
added a commit
that referenced
this pull request
Oct 20, 2026
…ged (#22) (#23) The drops-are-silent assertion from #20 required zero log lines, so one loopback send failing on the Java 8 runner turned main red after #21. Now only "could not deliver" lines are allowed, and far fewer of them than there were drops. A client that logged each drop still fails it, and the failure message prints the lines instead of only their count. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Stage A documentation accuracy sweep. Every README section, the class and method Javadoc, the
pom.xmldescription and version, and thebuild.ymlmatrix comment were checked againstTraceClient.java. Two gaps were found, both in the README:reportpromises" → Bounded. The row sits directly under "Drops are logged atFINEif you gave a logger". A report dropped by a full queue goes throughThreadPoolExecutor.DiscardPolicyand is never logged, at any level. The row now says so.queue_isBoundedAndDropsRatherThanGrowsnow attaches aRecordingHandlerand asserts that no record is logged across the flood. Every delivered report gets a201, so any record would have to come from a drop.enabled:line inside the block is a tag, not the switch. Both behaviours were already stated inparseServerWideConfig's Javadoc and pinned byserverWideTags_blockEndsAtTheNextUnindentedLineOrEndOfFileandserverWideTags_aHashIsACommentOnlyAfterWhitespace.No production code changed. The "Opting out" and "Keys" sections were left untouched.
No tracking issue: both gaps were found during the sweep.
Test plan
mvn -B verifylocally (Java 21):Tests run: 78, Failures: 0, Errors: 0, Skipped: 0build (8),build (17),build (21)green on the PR headDeferred issues
withVersionexceedsMAX_TAGS): skipped. It changes what is sent on the wire and is marked as needing a maintainer decision.enabled:does not disable): reopened this cycle. It had been auto-closed by a GitHub closing keyword ("resolves" followed by the issue number) in PR Cover the line reader's escapes, comments and quoted switch #16's body, although the behaviour is unchanged. It is skipped for the same reason as withVersion pushes an event already at MAX_TAGS over the server's tag limit #13, since it touches the opt-out contract. Nothing about quoting was added to the README "Opting out" row, so as not to pre-empt either of the options the issue lists.This PR description was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).
🤖 Generated with Claude Code
drafted by Claude on behalf of Daniel Stephenson