fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

CB-602: catch a config key that never reaches the example #98

Closed
agent wants to merge 0 commits from worker/cb602-ce257f-19 into main
pull from: worker/cb602-ce257f-19
merge into: fleet:main
Conversation 1 Commits - Files Changed -
agent commented 2026-08-16 18:06:58 +02:00
Member
Copy Link
Copy Source

Adds a code->example drift guard for bridged.yaml's schema.

bridged.yaml is gitignored, so bridged.example.yaml is the only committed description of the config schema. Two existing tests (shippedExampleConfigParses, everyOptionalKnobDocumentedInTheExampleBinds) only check the example->code direction. Nothing caught a brand-new top-level key nobody documented.

  • Made BridgedConfig.KNOWN_TOP_LEVEL_KEYS package-private (was private) so a test can read the parser's own accepted key set directly, instead of hand-maintaining a duplicate list.
  • Added everyKnownTopLevelKeyIsDocumentedInTheExample: scans bridged.example.yaml as TEXT (not parsed YAML) for each known key at column 0, live (key:) or commented (# key:). Parsing as YAML was the mistake CB-597 traced: most of the example is deliberately commented out, so a parsed-key-set comparison reports whole sections as missing when they are documented as comments.
  • Added commentedOnlyTopLevelKeyCountsAsDocumented and absentTopLevelKeyIsNotDocumented as direct unit tests of the scanning helper, proving the comment case is handled correctly in both directions.
  • Failure message names the missing key(s) and says what to do: document it in the example, commented out if optional.

Verified the guard actually catches drift: temporarily added a throwaway top-level key (cb602DriftProbe) to KNOWN_TOP_LEVEL_KEYS, ran the new test, watched it fail with the expected message, then reverted the change (confirmed via git diff — zero occurrences of the throwaway key left).

Tests: mvn clean install, run unpiped. 827 tests, 1 failure: AmqpReplyInboxRecoveryRaceTest.recoverySweepDoesNotFailAPublishThatRegistersWhileItIsRunning, the known-flaky test called out in the ticket (confirmed flaky by re-running it alone: passed). BridgedConfigTest itself: 85/85 green.

Did not touch the cosmetic primary: duplication in the example, as instructed.

Adds a code->example drift guard for bridged.yaml's schema. bridged.yaml is gitignored, so bridged.example.yaml is the only committed description of the config schema. Two existing tests (shippedExampleConfigParses, everyOptionalKnobDocumentedInTheExampleBinds) only check the example->code direction. Nothing caught a brand-new top-level key nobody documented. - Made BridgedConfig.KNOWN_TOP_LEVEL_KEYS package-private (was private) so a test can read the parser's own accepted key set directly, instead of hand-maintaining a duplicate list. - Added everyKnownTopLevelKeyIsDocumentedInTheExample: scans bridged.example.yaml as TEXT (not parsed YAML) for each known key at column 0, live (key:) or commented (# key:). Parsing as YAML was the mistake CB-597 traced: most of the example is deliberately commented out, so a parsed-key-set comparison reports whole sections as missing when they are documented as comments. - Added commentedOnlyTopLevelKeyCountsAsDocumented and absentTopLevelKeyIsNotDocumented as direct unit tests of the scanning helper, proving the comment case is handled correctly in both directions. - Failure message names the missing key(s) and says what to do: document it in the example, commented out if optional. Verified the guard actually catches drift: temporarily added a throwaway top-level key (cb602DriftProbe) to KNOWN_TOP_LEVEL_KEYS, ran the new test, watched it fail with the expected message, then reverted the change (confirmed via git diff — zero occurrences of the throwaway key left). Tests: mvn clean install, run unpiped. 827 tests, 1 failure: AmqpReplyInboxRecoveryRaceTest.recoverySweepDoesNotFailAPublishThatRegistersWhileItIsRunning, the known-flaky test called out in the ticket (confirmed flaky by re-running it alone: passed). BridgedConfigTest itself: 85/85 green. Did not touch the cosmetic primary: duplication in the example, as instructed.
agent added 1 commit 2026-08-16 18:06:59 +02:00
CB-602: guard against a config key that never reaches the example
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Failing after 1m24s
Details
32bf324a1e 
BridgedConfig.KNOWN_TOP_LEVEL_KEYS is now package-private so a test can assert
every key the parser accepts appears in bridged.example.yaml — live or
commented-out, since the file is gitignored and the example is the only
committed description of the config schema. The existing tests only checked
the example->code direction; this adds code->example.
ltms commented 2026-08-16 18:17:56 +02:00
Owner
Copy Link
Copy Source

Merged locally into main and pushed. Gitea cannot mark a locally merged PR as merged, so I am closing it by hand — merged, not rejected. Verification is written up on the linked issue.

Merged locally into `main` and pushed. Gitea cannot mark a locally merged PR as merged, so I am closing it by hand — **merged, not rejected**. Verification is written up on the linked issue.
ltms closed this pull request 2026-08-16 18:17:56 +02:00
Some checks are pending
CI / contract (pull_request) Successful in 49s
Details
CI / build (pull_request) Failing after 1m24s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#98
Delete Branch "worker/cb602-ce257f-19"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?