Repository navigation
fix(cli): kates conformity lint refuses a key set twice to the same value, as the check does - #437
Merged
Merged
Conversation
…alue, as the check does A key set twice to the same value was a lint warning, so lint exited 0, but kates conformity check then failed with exit 2 before it called the API: conformityJSON decodes into any, and yaml.v3 refuses the repeated key there. The Kates API refuses a repeated JSON key too (STRICT_DUPLICATE_DETECTION). duplicate-key is now an error, still fixable: kates conformity fmt keeps the first, as for duplicate-item. The CLI tests hold lint and check to the same outcome for it. The shared corpus can't: KafkaReferenceCorpusTest converts YAML with readTree, which keeps the last value, so the reader never sees the repeat. The CLI Reference says lint refuses a key set twice and fmt fixes it.
bmscomp
added a commit
that referenced
this pull request
Oct 21, 2026
…alue, as the check does (#437) A key set twice to the same value was a lint warning, so lint exited 0, but kates conformity check then failed with exit 2 before it called the API: conformityJSON decodes into any, and yaml.v3 refuses the repeated key there. The Kates API refuses a repeated JSON key too (STRICT_DUPLICATE_DETECTION). duplicate-key is now an error, still fixable: kates conformity fmt keeps the first, as for duplicate-item. The CLI tests hold lint and check to the same outcome for it. The shared corpus can't: KafkaReferenceCorpusTest converts YAML with readTree, which keeps the last value, so the reader never sees the repeat. The CLI Reference says lint refuses a key set twice and fmt fixes it.
bmscomp
added a commit
that referenced
this pull request
Oct 21, 2026
…alue, as the check does (#437) A key set twice to the same value was a lint warning, so lint exited 0, but kates conformity check then failed with exit 2 before it called the API: conformityJSON decodes into any, and yaml.v3 refuses the repeated key there. The Kates API refuses a repeated JSON key too (STRICT_DUPLICATE_DETECTION). duplicate-key is now an error, still fixable: kates conformity fmt keeps the first, as for duplicate-item. The CLI tests hold lint and check to the same outcome for it. The shared corpus can't: KafkaReferenceCorpusTest converts YAML with readTree, which keeps the last value, so the reader never sees the repeat. The CLI Reference says lint refuses a key set twice and fmt fixes it.
bmscomp
added a commit
that referenced
this pull request
Oct 21, 2026
…dminless plan with what shipped (#444) The book teaches the conformity language in its Conformity Checks chapter, but had no place that lists every field, value kind, rule id, report field and lint code. A new appendix does, after the version matrix; the chapter, the CLI Reference, the Reference part's intro and the README point to it. It is written against main as of #443: - a key set twice to the same value is a lint error that fmt fixes (#437); - with rbac.scope=namespace, zones, skew and rack awareness read the EndpointSlices of the brokers' headless Service when nodes can't be listed, and podMonitor looks in the Kafka namespace only (#439); - a refused get of the Kafka resource is a 503 naming the grant (#439), which the API Reference now says too; - the chart sets the checked namespace and cluster from networkPolicy.kafka.namespace and kafka.clusterName (#441). plans/adminless-kubernetes.md is the plan behind #439, with a status block naming what shipped in #439 and #441-#443, where the work departed from it (EndpointSlice zones; orphan recovery left on), and what is still open.
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
1 participant
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.
Why
kates conformity lintandkates conformity checkdisagreed about a key set twice to the same value. Withcount: 3twice underspec.brokers, lint printed aduplicate-keywarning and exited 0. Check printed the same warning, then failed with exit 2 before it called the API:That error comes from
conformityJSON, which decodes intoany, where yaml.v3 refuses a repeated key. The Kates API refuses one too (STRICT_DUPLICATE_DETECTIONinKafkaReferenceReader). So the CLI Reference's promise that a lint warning doesn't stop the check was false for this case.What changes
duplicate-keyis now an error, still fixable:kates conformity fmtkeeps the first, as it already does forduplicate-item(also an error thatfmtfixes). Lint now refuses what check and the API refuse, and check stops at lint's own message instead of a yaml.v3 one.I chose this over letting
conformityJSONaccept the repeat and send the first value. That would have made check send something the API refuses from any other client, and kept lint and the API apart.cli/internal/conformity/compile.go: severity and theduplicates()comment.TestDuplicatesexpects an error.TestConformityLintPassesWithWarningsOnlynow uses aduplicate-valuewarning, which stays a warning because the API accepts a repeated list value.TestConformityCheckStopsOnALintErrorBeforeTheAPIalso covers a same-value duplicate key. It asserts lint exits 1, and that check exits 2 with lint's message, without calling the API. Without the fix it fails with the yaml.v3 error above.duplicate-keyorconflicting-key), and fmt says it fixesduplicate-key,duplicate-itemandduplicate-value.Deliberately not done
testdata/invalidis shared withKafkaReferenceCorpusTest, whosejson()helper converts YAML withYAMLMapper().readTree. That keeps the last value of a repeated key (checked with the 2.18 jars:count: 3twice becomes{"count":3}), so the reader never sees the duplicate and the Java test would fail. The CLI tests cover the agreement instead.appendix-conformity-language.md) isn't on main yet. Its duplicate-key sentence in "The Document" and itsduplicate-keyrow need the same change. The exact wording is in a hand-over note for the session writing it.Tests
Run locally:
cli:go test ./...,go vet ./...,golangci-lint run --new-from-rev=origin/main ./...(0 issues),govulncheck ./...scripts/check-cli-style.sh,bash scripts/check-cli-compat.shkates:./mvnw test -Dquarkus.grpc.codegen.skip=true -Dquarkus.http.test-port=0(cli/**triggers the backend's Build & Test). 1,490 tests, 0 failures, 1 skipped;KafkaReferenceCorpusTest51/51.scripts/check-book-style.sh,gen-version-matrix.sh --check,gen-chart-table.sh --check,check-book-contrast.py,check-mermaid.shcheck-book-fragments.py(7,738 fragment links land)Left to CI: the PDF render (the two added sentences are ASCII with code spans),
*ITtests, the native image and Docker builds.