Repository navigation
test: benchmark the installation token cache hit - #71
Merged
Merged
Conversation
Almost every Token() call returns a cached token, and nothing measured
that path. A change that reintroduced work there -- an allocation per
call, or a lost cache -- would not fail any test, since the existing
ones all assert behaviour rather than cost.
The benchmark asserts the server saw exactly one request after the
loop. Without that check it would still report a number if caching
broke; it would just be timing HTTP round trips and calling them cache
hits.
Current baseline on an 18-core M-series machine:
BenchmarkInstallationTokenSource_CacheHit-18
31613367 34.90 ns/op 0 B/op 0 allocs/op
No new concurrency tests: TestReuseTokenSourceWithSkew already pins
the collapse to one upstream fetch, and Test_WithInstallationExpirySkew_Wiring
pins that the constructor uses the wrapper. Mutation testing confirmed
both catch a disabled cache, a lock dropped across the refresh, and an
unwrapped installation source.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #71 +/- ##
=======================================
Coverage 98.88% 98.88%
=======================================
Files 5 5
Lines 447 447
=======================================
Hits 442 442
Misses 5 5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Description
Almost every
Token()call returns a cached token, and nothing measured that path. Achange that reintroduced work there — an allocation per call, or a lost cache — would not
fail any existing test, because they all assert behaviour rather than cost.
Baseline on an 18-core M-series machine:
The benchmark asserts the test server saw exactly one request after the loop. Without that
check it would still print a number if caching broke — it would just be timing HTTP round
trips and calling them cache hits. Verified against a build with the cache removed:
What is deliberately not here
No concurrency tests. I wrote a set that counted HTTP requests under 200 concurrent
callers, then checked whether they earned their place by mutating the source:
TestReuseTokenSourceWithSkewTestReuseTokenSourceWithSkewNewInstallationTokenSourceTest_WithInstallationExpirySkew_WiringAll three were already covered, so the new tests were redundant and were dropped. The
existing collapse test is also the stronger assertion: it checks every goroutine receives
the same token, not just that one request was made.
Type of Change
Testing
go test ./...passes andgolangci-lint run ./...reports 0 issues. The benchmark doesnot run during
go test, so CI time is unchanged.Documentation
CHANGELOG.md is untouched: this adds no library behaviour for a consumer to act on.
Checklist
go.modand the CI matrix