Register quota metrics unconditionally - #6253
Open
delthas wants to merge 2 commits into
Open
Conversation
❌ 10 Tests Failed:
View the full list of 11 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
delthas
marked this pull request as ready for review
August 12, 2026 14:09
SylvainSenechal
approved these changes
Aug 12, 2026
delthas
force-pushed
the
improvement/CLDSRV-972/call-isquotaenabled
branch
from
August 12, 2026 15:33
b448fe5 to
d580a11
Compare
delthas
requested review from
francoisferrand
and removed request for
benzekrimaha
August 13, 2026 07:49
Contributor
Author
|
Requested @francoisferrand in place of Maha Benzekri, who is currently on PTO. |
delthas
force-pushed
the
improvement/CLDSRV-972/call-isquotaenabled
branch
from
August 13, 2026 08:10
d580a11 to
fcefd5a
Compare
Base automatically changed from
improvement/CLDSRV-971/quota-metrics-retrieval-code-label
to
development/9.4
August 13, 2026 08:39
Contributor
Hello delthas,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Contributor
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
|
francoisferrand
left a comment
francoisferrand
left a comment
Contributor
There was a problem hiding this comment.
- I think creating the metrics is harmless (it was already the case); and it avoids adding all the ?. → just create them always
- less sure how to fix crrCacheToPom
Both quota gates in monitoringHandler tested config.isQuotaEnabled -- the function reference rather than a call -- so both were always true and all six quota metrics were always registered. Drop the conditionals rather than calling the function. Always registering is what has actually happened since these checks were written, nothing depends on the metrics disappearing when quota is off, and gating registration would mean guarding every metric touch point against a metric that was never created: crrCacheToProm reached bucketsWithQuota unguarded, and the scuba wrapper observes its histogram in a finally block, on a path the Veeam capacity route hits with no quota gating at all. Behaviour is unchanged -- the six s3_cloudserver_quota_* series are exposed exactly as before -- so this is a dead code removal. Issue: CLDSRV-972
delthas
changed the title
delthas
force-pushed
the
improvement/CLDSRV-972/call-isquotaenabled
branch
from
August 14, 2026 15:32
fcefd5a to
33f77af
Compare
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
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
4 participants
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.
Stacked on #6252 — review that one first. This PR's diff is only the last two
commits; retarget to
development/9.4once #6252 merges.Both quota gates in
lib/utilities/monitoringHandler.jstestedconfig.isQuotaEnabled— the function reference rather than a call — so bothwere always true, and all six quota metrics have always been registered.
Rather than calling the function, the conditionals are removed. Always
registering is what has actually happened since these checks were written,
nothing depends on the metrics disappearing when quota is off, and gating
registration would mean guarding every metric touch point against a metric that
was never created:
crrCacheToPromreachedbucketsWithQuotaunguarded, andthe scuba wrapper observes its histogram in a
finallyblock, on a path theVeeam capacity route reaches with no quota gating at all.
Behaviour is unchanged — the six
s3_cloudserver_quota_*series are exposedexactly as before — so this is a dead code removal rather than a metric surface
change.
Issue: CLDSRV-972