Repository navigation
refactor(inkless:consume): drop four never-recorded fetch metrics - #787
Merged
Merged
Conversation
CacheQueryTime, CacheStoreTime, CacheHitCount and CacheMissCount were registered on the consumer fetch group and documented in metrics.rst, but nothing ever recorded them: cacheQueryFinished, cacheStoreFinished and cacheHit(boolean) had no callers anywhere in the tree. An operator graphing any of the four saw an empty series and no way to tell that from a quiet broker. Remove the constants, the templates, the registrations, the recording methods and the removeMetric calls together, so the class and the generated reference agree, and regenerate metrics.rst. Cache hit and miss stay observable: CaffeineCacheMetrics publishes Caffeine's own hitCount and missCount, and the byte split is CacheHitBytesPerSec against StorageBytesInPerSec. CacheQueryTime and CacheStoreTime have no equivalent, but they never carried a sample, so nothing is lost that ever worked. Note the names did appear in the reference, so a dashboard referencing them will now show a missing metric rather than an empty one.
Two cosmetic fixes in InklessFetchMetrics, split out so they do not sit in a commit that changes behavior: the recordLaggingConsumerRejection javadoc had paragraphs the renderer ran together for want of a <p>, and the CacheSize gauge took a lambda where a method reference reads the same.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The removed metrics have no call sites in the codebase and the documentation update matches the updated metric template list, so the change should not break compilation or runtime behavior.
Pull request overview
This PR removes four consumer fetch metrics (CacheQueryTime, CacheStoreTime, C
8000
acheHitCount, CacheMissCount) that were registered and documented but never actually recorded anywhere, aligning the runtime metrics set with the generated docs/inkless/metrics.rst.
Changes:
- Remove the unused cache timing / hit-miss metric constants, templates, registrations, recording methods, and
removeMetriccalls fromInklessFetchMetrics. - Regenerate
docs/inkless/metrics.rstto drop the four metric rows. - Minor cleanup in
InklessFetchMetrics(usecache::sizefor the cache size gauge; improve Javadoc paragraph formatting).
File summaries
| File | Description |
|---|---|
| storage/inkless/src/main/java/io/aiven/inkless/consume/InklessFetchMetrics.java | Removes never-recorded metric definitions/recorders and tightens up the cache-size gauge/Javadoc so published metrics match behavior. |
| docs/inkless/metrics.rst | Removes the four metric entries so operator docs reflect what brokers can actually emit. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
jeqo
marked this pull request as ready for review
September 8, 2026 12:11
giuseppelillo
approved these changes
Sep 9, 2026
jeqo
added a commit
that referenced
this pull request
Sep 9, 2026
* refactor(inkless:consume): drop four never-recorded fetch metrics CacheQueryTime, CacheStoreTime, CacheHitCount and CacheMissCount were registered on the consumer fetch group and documented in metrics.rst, but nothing ever recorded them: cacheQueryFinished, cacheStoreFinished and cacheHit(boolean) had no callers anywhere in the tree. An operator graphing any of the four saw an empty series and no way to tell that from a quiet broker. Remove the constants, the templates, the registrations, the recording methods and the removeMetric calls together, so the class and the generated reference agree, and regenerate metrics.rst. Cache hit and miss stay observable: CaffeineCacheMetrics publishes Caffeine's own hitCount and missCount, and the byte split is CacheHitBytesPerSec against StorageBytesInPerSec. CacheQueryTime and CacheStoreTime have no equivalent, but they never carried a sample, so nothing is lost that ever worked. Note the names did appear in the reference, so a dashboard referencing them will now show a missing metric rather than an empty one. * refactor(inkless:consume): tidy metrics javadoc and gauge lambda Two cosmetic fixes in InklessFetchMetrics, split out so they do not sit in a commit that changes behavior: the recordLaggingConsumerRejection javadoc had paragraphs the renderer ran together for want of a <p>, and the CacheSize gauge took a lambda where a method reference reads the same.
jeqo
added a commit
that referenced
this pull request
Sep 9, 2026
* refactor(inkless:consume): drop four never-recorded fetch metrics CacheQueryTime, CacheStoreTime, CacheHitCount and CacheMissCount were registered on the consumer fetch group and documented in metrics.rst, but nothing ever recorded them: cacheQueryFinished, cacheStoreFinished and cacheHit(boolean) had no callers anywhere in the tree. An operator graphing any of the four saw an empty series and no way to tell that from a quiet broker. Remove the constants, the templates, the registrations, the recording methods and the removeMetric calls together, so the class and the generated reference agree, and regenerate metrics.rst. Cache hit and miss stay observable: CaffeineCacheMetrics publishes Caffeine's own hitCount and missCount, and the byte split is CacheHitBytesPerSec against StorageBytesInPerSec. CacheQueryTime and CacheStoreTime have no equivalent, but they never carried a sample, so nothing is lost that ever worked. Note the names did appear in the reference, so a dashboard referencing them will now show a missing metric rather than an empty one. * refactor(inkless:consume): tidy metrics javadoc and gauge lambda Two cosmetic fixes in InklessFetchMetrics, split out so they do not sit in a commit that changes behavior: the recordLaggingConsumerRejection javadoc had paragraphs the renderer ran together for want of a <p>, and the CacheSize gauge took a lambda where a method reference reads the same.
jeqo
added a commit
that referenced
this pull request
Sep 9, 2026
* refactor(inkless:consume): drop four never-recorded fetch metrics CacheQueryTime, CacheStoreTime, CacheHitCount and CacheMissCount were registered on the consumer fetch group and documented in metrics.rst, but nothing ever recorded them: cacheQueryFinished, cacheStoreFinished and cacheHit(boolean) had no callers anywhere in the tree. An operator graphing any of the four saw an empty series and no way to tell that from a quiet broker. Remove the constants, the templates, the registrations, the recording methods and the removeMetric calls together, so the class and the generated reference agree, and regenerate metrics.rst. Cache hit and miss stay observable: CaffeineCacheMetrics publishes Caffeine's own hitCount and missCount, and the byte split is CacheHitBytesPerSec against StorageBytesInPerSec. CacheQueryTime and CacheStoreTime have no equivalent, but they never carried a sample, so nothing is lost that ever worked. Note the names did appear in the reference, so a dashboard referencing them will now show a missing metric rather than an empty one. * refactor(inkless:consume): tidy metrics javadoc and gauge lambda Two cosmetic fixes in InklessFetchMetrics, split out so they do not sit in a commit that changes behavior: the recordLaggingConsumerRejection javadoc had paragraphs the renderer ran together for want of a <p>, and the CacheSize gauge took a lambda where a method reference reads the same.
jeqo
added a commit
that referenced
this pull request
Sep 10, 2026
* docs(inkless:sync): archive the 0.48 cherry-pick sessions for 4.1, 4.2, 4.3 Session logs for bringing the three active release branches up to main (5fa6669, #784) ahead of the 0.48 release. inkless-4.3 took its 8 commits clean. inkless-4.2 and inkless-4.1 took 19 each; the logs record the conflict resolutions and the sync(compile)/sync(test) adaptations needed for the 4.2.1 and 4.1.2 APIs (Record package, LogReadResult constructor, Seq-based DelayedFetch statuses). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> docs(inkless:sync): complete the 0.48 cherry-pick session logs The three branches took six more main commits (#794, #787, #792, #793, tables and the verification that covered them. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): list inkless-4.3 as an active release branch inkless-4.3 is on Kafka 4.3.1 (#779) and gets its first Kafka-base tag with 0.48, so it moves from Planned to Active in RELEASES.md. The release workflow header names it among the branches the cherry-pick sync has to cover before a run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): add 0.48 changelog entry Generated from inkless-release-0.47..inkless-release-0.48 and curated: every metric delta traced to its commit, the four config default changes the configs.rst diff shows added next to the four new keys, and the V28 lock on logs described for operators. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
giuseppelillo
pushed a commit
that referenced
this pull request
Sep 18, 2026
* docs(inkless:sync): archive the 0.48 cherry-pick sessions for 4.1, 4.2, 4.3 Session logs for bringing the three active release branches up to main (5fa6669, #784) ahead of the 0.48 release. inkless-4.3 took its 8 commits clean. inkless-4.2 and inkless-4.1 took 19 each; the logs record the conflict resolutions and the sync(compile)/sync(test) adaptations needed for the 4.2.1 and 4.1.2 APIs (Record package, LogReadResult constructor, Seq-based DelayedFetch statuses). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> docs(inkless:sync): complete the 0.48 cherry-pick session logs The three branches took six more main commits (#794, #787, #792, #793, tables and the verification that covered them. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): list inkless-4.3 as an active release branch inkless-4.3 is on Kafka 4.3.1 (#779) and gets its first Kafka-base tag with 0.48, so it moves from Planned to Active in RELEASES.md. The release workflow header names it among the branches the cherry-pick sync has to cover before a run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): add 0.48 changelog entry Generated from inkless-release-0.47..inkless-release-0.48 and curated: every metric delta traced to its commit, the four config default changes the configs.rst diff shows added next to the four new keys, and the V28 lock on logs described for operators. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
giuseppelillo
pushed a commit
that referenced
this pull request
Sep 18, 2026
* docs(inkless:sync): archive the 0.48 cherry-pick sessions for 4.1, 4.2, 4.3 Session logs for bringing the three active release branches up to main (5fa6669, #784) ahead of the 0.48 release. inkless-4.3 took its 8 commits clean. inkless-4.2 and inkless-4.1 took 19 each; the logs record the conflict resolutions and the sync(compile)/sync(test) adaptations needed for the 4.2.1 and 4.1.2 APIs (Record package, LogReadResult constructor, Seq-based DelayedFetch statuses). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> docs(inkless:sync): complete the 0.48 cherry-pick session logs The three branches took six more main commits (#794, #787, #792, #793, tables and the verification that covered them. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): list inkless-4.3 as an active release branch inkless-4.3 is on Kafka 4.3.1 (#779) and gets its first Kafka-base tag with 0.48, so it moves from Planned to Active in RELEASES.md. The release workflow header names it among the branches the cherry-pick sync has to cover before a run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): add 0.48 changelog entry Generated from inkless-release-0.47..inkless-release-0.48 and curated: every metric delta traced to its commit, the four config default changes the configs.rst diff shows added next to the four new keys, and the V28 lock on logs described for operators. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
giuseppelillo
pushed a commit
that referenced
this pull request
Sep 24, 2026
* docs(inkless:sync): archive the 0.48 cherry-pick sessions for 4.1, 4.2, 4.3 Session logs for bringing the three active release branches up to main (5fa6669, #784) ahead of the 0.48 release. inkless-4.3 took its 8 commits clean. inkless-4.2 and inkless-4.1 took 19 each; the logs record the conflict resolutions and the sync(compile)/sync(test) adaptations needed for the 4.2.1 and 4.1.2 APIs (Record package, LogReadResult constructor, Seq-based DelayedFetch statuses). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> docs(inkless:sync): complete the 0.48 cherry-pick session logs The three branches took six more main commits (#794, #787, #792, #793, tables a 8000 nd the verification that covered them. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): list inkless-4.3 as an active release branch inkless-4.3 is on Kafka 4.3.1 (#779) and gets its first Kafka-base tag with 0.48, so it moves from Planned to Active in RELEASES.md. The release workflow header names it among the branches the cherry-pick sync has to cover before a run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(inkless:release): add 0.48 changelog entry Generated from inkless-release-0.47..inkless-release-0.48 and curated: every metric delta traced to its commit, the four config default changes the configs.rst diff shows added next to the four new keys, and the V28 lock on logs described for operators. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <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
30E6
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.
CacheQueryTime,CacheStoreTime,CacheHitCountandCacheMissCountare registered on the consumer fetch group and documented inmetrics.rst, but nothing records them:cacheQueryFinished,cacheStoreFinishedandcacheHit(boolean)have no callers anywhere in the tree. An operator graphing any of the four sees an empty series with no way to tell that from a quiet broker.Remove the constants, templates, registrations, recording methods and
removeMetriccalls together, so the class and the generated reference agree again.Operator impact
Four documented metric names disappear. They never carried a sample, so no dashboard loses data - but one referencing them moves from an empty series to a missing metric, which some tools surface differently.
Cache hit and miss stay observable elsewhere:
CaffeineCacheMetricspublishes Caffeine's ownhitCountandmissCount, and the byte split isCacheHitBytesPerSecagainstStorageBytesInPerSec.CacheQueryTimeandCacheStoreTimehave no equivalent, and gain none here - they simply never worked.Commits
drop four never-recorded fetch metrics- the removal, plus the regeneratedmetrics.rst.tidy metrics javadoc and gauge lambda- two cosmetic fixes in the same class, split out so they do not sit in a commit that changes what the broker publishes.