Repository navigation
fix(tune): no command or endpoint ranks tuning steps that no run measured: the tuning report is gone - #386
Merged
Conversation
…ured: the tuning report is gone
kates tune run replication measures one configuration, the backend's
defaults for the type (RF 3, acks=all). Yet kates tune report, through
GET /api/tests/{id}/report/tuning, showed three steps, "RF=1, acks=1",
"RF=2, acks=all" and "RF=3, min.isr=2, acks=all", all with that one
run's numbers. Its best step was the first with throughput above -1,
so always step 0, and the recommendation read "RF=1, acks=1 balances
durability with acceptable throughput". TUNE_ACKS likewise always
recommended acks=0. No step but the run's own was ever measured.
The ranking is now deleted rather than faked:
- TuningTestRunner loses buildReport, buildRecommendation and the
stepsFor tables; TuningReport and its two native reflection entries
go, and so does the /report/tuning endpoint, which now answers 404.
- kates tune report goes, with its client call and types. kates tune
run's hint names kates report show <id>, which shows the one real
measurement.
- kates tune types reports 1 step per type, and its descriptions say
what a run measures instead of naming a sweep. So do the TUNE_*
descriptions in kates test types and kates explain, and the tune
line in kates --help.
The MCP caveat tuning-one-measurement stays, reworded: a TUNE_* run
measures one setting and compares none. Its TuningTestRunner ref is
dropped, and the five comment refs into ReportResource.java move up
22 lines. The book, README, doc entries and the kates-cli skill no
longer claim a sweep, and point to kates report show and kates lab.
Scripts that call kates tune report or the endpoint now fail.
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.
Plan PR 15 of the audit fix plan (finding 13). Breaking:
GET /api/tests/{id}/report/tuningnow answers 404 andkates tune reportno longer exists, so scripts that call either one fail. Lands after the earlier plan PRs; see Landing.Why
kates tune reportand the endpoint behind it ranked configurations that no run measured. Checked in the code on main:kates tune run <type>sends no spec.TestTypeDefaultsgives everyTUNE_*type the LOAD replication factor, partitions and min ISR withacks"all", andTestOrchestrator(case TUNE_REPLICATION, …, :1725-1726) builds one produce task,<id>-tune-0, from that spec.TuningTestRunner.buildReporttook 3 to 6 labelled configurations from thestepsFortables ("RF=1, acks=1", "RF=2, acks=all", "RF=3, min.isr=2, acks=all" forTUNE_REPLICATION) and gave every step the same summary of that one run.summary.avgThroughputRecPerSec() > bestThroughput, starting from -1. All steps carry the same value, so only step 0 passes, and with no summary the index stays 0 anyway.buildRecommendationread "RF=1, acks=1 balances durability with acceptable throughput" forTUNE_REPLICATIONand "acks=0 gives the best latency for the required safety level" forTUNE_ACKS.TUNE_COMPRESSIONrecommendednone,TUNE_BATCHING16KB / 0ms andTUNE_PARTITIONS1 partition / 1 producer. On the tie,findWorstStepalso picked step 0, so the CLI table showed a BEST row and no WORST row.tuning-one-measurementrecorded this. CLI and REST users got the recommendation with no warning.kates tune typesrepeated the claim. It reportedstepsFor(type).size()steps (3 to 6) and descriptions such as "Sweeps batch.size and linger.ms to find optimal throughput". The README, the book,kates --help,kates test typesandkates explainalso called these types sweeps.The ranking is deleted rather than faked.
kates report show <id>already shows the one real measurement.Changes
Backend (
kates/)TuningTestRunner:buildReport,buildRecommendationand thestepsFortables are deleted, with therepositoryandreportGeneratorfields and the imports only they used.availableTuningTestsreportssteps: 1, and each description says what a run measures ("Measures throughput and latency at the spec's acks setting").report/TuningReport.javais deleted, and so are its two entries (TuningReport,TuningReport.TuningStep) inNativePayloadReflectionConfig.ReportResource: the injectedtuningRunnerfield andGET {id}/report/tuningare gone.GET tuning/typesstays; it calls the staticavailableTuningTests. Every line after the endpoint moves up 22.ReportingApiIT.tuningCatalogIsServedIndependentlyOfAnyRun: the 404 check for/report/tuning, its comment and the blank line above them are removed. The check would still pass, because a missing route also answers 404, but its comment would be false. The catalog assertion stays.CLI (
cli/)cmd/tune.go:tune reportis gone, withtuneReportResult,tuneStepRow,buildTuneReport,renderTuneReport,metricValue,metricStr,findWorstStepand thetuneWorststyle.tune run's hint readsView results: kates report show <id>. Thetuneandtune runLong texts say a run measures one configuration and compares none, andtune runpoints tokates labfor comparing settings.client/client.goandclient/types.go:ReportTuning,TuningReportandTuningStepare deleted.TuningTypesandTuningTypeInfostay.cmd/helpers.godescribeType: the fiveTUNE_*descriptions, used bykates test typesandkates explain, say "Measures throughput and latency at one …" instead of naming a sweep.cmd/root.go: thetuneline inkates --helpreads "Tuning tests, each measuring one configuration".cmd/data/doc_entries.yaml: thetune reportentry is deleted.tune runandtune typesare reworded. Intune run'ssee_also,report showreplacestune report;tune typesjust loses it.kates mcpmcp_caveats.go: thetuning-one-measurementcaveat keeps its ID. Its text is now "A TUNE_* run executes one produce task with the spec's single configuration: it measures one setting and compares none." Its ref toTuningTestRunner.java:101-139, which no longer exists, is dropped. The anchoredTestOrchestrator.java:1725-1726ref andSpecFactory.java:38-39are unchanged.ReportResource.javamove up 22, each checked against the new file:mcp_tools_runs.go318-327 → 296-305 (computeDeltas), 293-305 → 271-283 (the compare loop), 307-313 → 285-291 (the deltas), 141-142 → 119-120 (Test run not found), andmcp_tools_runs_test.go152-153 → 130-131.Docs
docs/book/10-cli-reference.md: thetune reportsection is deleted. The family table liststune run,typesand asks how one setting performs, not which performs best. The Tuning Commands intro says a run measures one setting, points tokates report show <id>, and points tokates lab, whose auto-sweep runs one test per value. The type table says each type measures the default.docs/book/05-test-types.mdandappendix-a-glossary.md: "parameter-sweep" and "(parameter sweeps)" are dropped.README.md: "plus configuration sweeps (kates tune run)" is dropped.skills/kates-cli/SKILL.md:tune reportleaves the JSON command list. TheTUNE_*rule says a run measures one setting and compares none, and to read it withreport show.Tests
Added:
TestTune_JSON'srunsubtest runskates tune run batchingwithout-o jsonand checks the output nameskates report show run-2.Removed with the code they tested:
client_test.goTestReportTuningand theReportTuningcase inescape_test.go.TestTune_JSON'sreportsubtest and its fixture, andrunsBackend'stuningmap with its handler case.Kept:
TestMCPGetRunTuningRunandTestMCPAssessRunScenarioAndTuning, since the caveat stays. The latter's check that no/report/tuningrequest is made stays valid.Run locally, passing:
git diff --name-only origin/main...HEAD: one commit, on a128f85. It changes 22 paths acrossREADME.md,cli/**(client, cmd,data/doc_entries.yaml),docs/book/**(05, 10, appendix-a),kates/**(main plusReportingApiIT) andskills/kates-cli/SKILL.md. Sets that apply: Java, CLI, Book, Docs and yamllint (a.yamlfile changed). Sets that do not: Charts, Makefile, workflows and shell. Main has since gained fix(make): the undeploy targets remove only their own Helm release, never the namespace's volumes or workloads #370, which touches none of these paths; the branch merges into main cleanly.cd kates && ./mvnw -o test -Dquarkus.grpc.codegen.skip=true -Dquarkus.http.test-port=0: BUILD SUCCESS in 3:19, 1466 tests, 0 failures, 0 errors, 0 skipped. Test-compile also compiledReportingApiIT../mvnw -o spotless:checkon JDK 25 (25.0.2-graalce): exit 0; the only output wassun.misc.Unsafedeprecation warnings.cd cli && go test ./...: every package ok, includingcmdwith the caveat-ref anchor tests.go test -p 1 ./... -race -count=1, the CI CLI Tests flags: exit 0.go vet ./...: clean.golangci-lint run --new-from-rev=origin/main ./...: 0 issues.govulncheck ./...: no vulnerabilities.scripts/check-cli-style.shandscripts/check-cli-compat.sh: OK.scripts/check-book-style.sh: exit 0. The ratchet prints below-baseline counts with an optional--updatehint; they appear on unchanged pages too, and nothing fails.scripts/gen-version-matrix.sh --check: in sync.scripts/gen-chart-table.sh --check: README chart table in sync.python3 scripts/check-book-contrast.py: all 170 colour pairs meet WCAG AA.scripts/check-mermaid.sh: 156 diagrams, 0 invalid.prepare-book-render.sh,quarto render docs/book --to html): 39 chapters prepared, 38 pages rendered, 0 warnings.check-book-fragments.pyon it: all 7,453 fragment links land on an id.yamllint -c .yamllint.yaml .github config chartspluscli/cmd/data/doc_entries.yaml: clean.Skipped locally:
lychee --offline --include-fragments: not installed. I checked by hand the 4 link targets the diff touches (#tuning-commands,05-test-types.md#test-type-overview,10-cli-reference.md,10b-lab.md); all exist, and the rendered fragment check passed.check-versions.sh: nocharts/**or helm-filter path changed.make check-help, actionlint and shellcheck: no Makefile,.github/**orscripts/**change.CI only:
./mvnw verify, which runs the*ITtests (including the editedReportingApiIT) under Docker/Testcontainerskates/**changed). Removing a registered DTO is what this job checks.cli/**andkates/**changed)Decisions
kates report show <id>already shows the one real measurement. The cost is the breaking removal above.stepsForis dropped too.kates tune typesreports 1 step, with reworded descriptions. Keeping the tables would have lefttune typesadvertising the same invented sweep.TUNE_*run still measures one setting, and an agent should still be told not to rank settings from it.bestStepIndexandrecommendationgo with the types. Nothing returns them now.@ApplicationScopedstays onTuningTestRunner. Nothing injects it any more, but it is harmless.kates report show <id>.kates report <id>does not exist:reportCmdhas noRunE.tune run's Long text and the book say a run measures "the backend's defaults for the type", which is whattune rungets, since it sends no spec. The caveat keeps the decided wording, "the spec's single configuration", which also covers aTUNE_*run created with a spec of its own.skills/kates-cli/SKILL.mdis edited now.eval/mcp/run.pyrecords the skill'sskill_sha256in a run's manifest (check_manifest), so a pending MCP eval run resumed after this merges will refuse until it is restarted or its manifest is updated.Deliberately not done
eval/mcp/test_metrics.py:179still has"kates tune report x": False. It passes, becauseclassifyworks on strings, and the decisions do not cover it.TestTune_JSON'stypessubtest fixture still servesSteps: 4and "Sweep batch.size" from the fake backend. It only checks that the CLI relays the answer.plans/mcp-server.mdstill citesTuningTestRunner.java:101-139and describes the tuning report. It is an old plan doc whose refs were already stale (TestOrchestrator.java:973-974), so it is left as is.Landing
Lands after #370 (plan PR 1), #371 (plan PR 2), #372 (plan PR 3), #373 (plan PR 4), #374 (plan PR 5), #375 (plan PR 6), #376 (plan PR 7), #377 (plan PR 8), #378 (plan PR 9), #379 (plan PR 10), #380 (plan PR 11), #381 (plan PR 12), #382 (plan PR 13) and #384 (plan PR 14). The files they share with this PR:
README.md.docs/book/10-cli-reference.md(fix(engine): run retention keeps the run a baseline names, so regression checks keep working #378 alsocli/cmd/mcp_caveats.go).cli/cmd/mcp_tools_runs.go.cli/cmd/mcp_tools_runs.go,docs/book/05-test-types.md,docs/book/10-cli-reference.md,docs/book/appendix-a-glossary.md.cli/cmd/mcp_caveats.go,cli/cmd/mcp_tools_runs.go,docs/book/05-test-types.md.cli/cmd/mcp_caveats.go,cli/cmd/mcp_tools_runs.go,cli/cmd/mcp_tools_runs_test.go.cli/cmd/mcp_caveats.go,skills/kates-cli/SKILL.md.cli/client/client_test.go,cli/client/types.go.A trial merge of this branch with each open PR's head is clean, and none of them adds a ref into
ReportResource.javaorTuningTestRunner.javaor mentionstune report.Rebase recipe: rebase onto main once they have merged. Then re-point any caveat or comment ref the merged changes moved, from a diff line map. The five
ReportResource.javarefs here are this PR's own move. The tuning caveat'sTestOrchestrator.java:1725-1726ref is anchored, so a merged edit that moves it shows up in the anchor test. Then reruncd cli && go test ./cmd -run TestMCPCaveat.