Item 5 of 15 of #168: "One mechanism for counters: Prometheus, not the cache_stats table". Starts when the schema item before it in #168's order is squash-merged to next.
Today (next at 989da78)
IncrementStats, IncrementUpstreamFetch and IncrementTransformCount in internal/imgcache/cache.go update the cache_stats table on every request (after #309, from a background goroutine), with a pending-count writer (internal/imgcache/pendingcounts.go) for writes that miss their deadline. In production nothing reads the table: Cache.Stats is reached only through Service.Stats, which no handler calls and no route exposes. #85 asks for the same numbers as Prometheus metrics, and the Prometheus registry pixa serves at /metrics is already a dependency. Two counting mechanisms do one job, and one of them writes to disk for no reader.
Definition of done
Cache hits, cache misses, upstream fetches, upstream bytes fetched and transforms are Prometheus counters held in process memory and registered on the registry /metrics serves; README.md's metrics line names them. Adding to one is an in-memory add, not a database call, so a cache hit still makes no database call.
cache_stats, Cache.Stats, Service.Stats, CacheStats, the Increment methods' database writes and the pending-count writer are gone, with their tests.
New tests show each counter rising by what one request of each kind adds.
This is the first step of #85; the rest of that issue (metrics collected without credentials set, and other pixa metrics) stays there.
Approval and tests
sneak asked for each main recommendation of #168 to be its own issue, built before 1.0, one at a time in the order listed (#168 (comment)). That instruction is his approval of this item, including its replacement of the database counters made correct under #56 and the deletion of the tests of the code it removes. Existing tests change only as this item needs: they follow code that moves or is renamed, and the tests of code this item removes go with it; no other assertion is weakened or dropped.
Model: opus-5-5
Item 5 of 15 of https://git.eeqj.de/sneak/pixa/issues/168: "One mechanism for counters: Prometheus, not the `cache_stats` table". Starts when the schema item before it in https://git.eeqj.de/sneak/pixa/issues/168's order is squash-merged to `next`.
## Today (`next` at `989da78`)
`IncrementStats`, `IncrementUpstreamFetch` and `IncrementTransformCount` in `internal/imgcache/cache.go` update the `cache_stats` table on every request (after https://git.eeqj.de/sneak/pixa/issues/309, from a background goroutine), with a pending-count writer (`internal/imgcache/pendingcounts.go`) for writes that miss their deadline. In production nothing reads the table: `Cache.Stats` is reached only through `Service.Stats`, which no handler calls and no route exposes. https://git.eeqj.de/sneak/pixa/issues/85 asks for the same numbers as Prometheus metrics, and the Prometheus registry pixa serves at `/metrics` is already a dependency. Two counting mechanisms do one job, and one of them writes to disk for no reader.
## Definition of done
- Cache hits, cache misses, upstream fetches, upstream bytes fetched and transforms are Prometheus counters held in process memory and registered on the registry `/metrics` serves; `README.md`'s metrics line names them. Adding to one is an in-memory add, not a database call, so a cache hit still makes no database call.
- `cache_stats`, `Cache.Stats`, `Service.Stats`, `CacheStats`, the `Increment` methods' database writes and the pending-count writer are gone, with their tests.
- New tests show each counter rising by what one request of each kind adds.
- This is the first step of https://git.eeqj.de/sneak/pixa/issues/85; the rest of that issue (metrics collected without credentials set, and other pixa metrics) stays there.
## Approval and tests
sneak asked for each main recommendation of https://git.eeqj.de/sneak/pixa/issues/168 to be its own issue, built before 1.0, one at a time in the order listed (https://git.eeqj.de/sneak/pixa/issues/168#issuecomment-153513). That instruction is his approval of this item, including its replacement of the database counters made correct under https://git.eeqj.de/sneak/pixa/issues/56 and the deletion of the tests of the code it removes. Existing tests change only as this item needs: they follow code that moves or is renamed, and the tests of code this item removes go with it; no other assertion is weakened or dropped.
Model: opus-5-5
clawbot
added this to the 1.0.0 milestone 2026-10-21 12:50:03 +02:00
clawbot
self-assigned this 2026-10-21 12:50:03 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Item 5 of 15 of #168: "One mechanism for counters: Prometheus, not the
cache_statstable". Starts when the schema item before it in #168's order is squash-merged tonext.Today (
nextat989da78)IncrementStats,IncrementUpstreamFetchandIncrementTransformCountininternal/imgcache/cache.goupdate thecache_statstable on every request (after #309, from a background goroutine), with a pending-count writer (internal/imgcache/pendingcounts.go) for writes that miss their deadline. In production nothing reads the table:Cache.Statsis reached only throughService.Stats, which no handler calls and no route exposes. #85 asks for the same numbers as Prometheus metrics, and the Prometheus registry pixa serves at/metricsis already a dependency. Two counting mechanisms do one job, and one of them writes to disk for no reader.Definition of done
/metricsserves;README.md's metrics line names them. Adding to one is an in-memory add, not a database call, so a cache hit still makes no database call.cache_stats,Cache.Stats,Service.Stats,CacheStats, theIncrementmethods' database writes and the pending-count writer are gone, with their tests.Approval and tests
sneak asked for each main recommendation of #168 to be its own issue, built before 1.0, one at a time in the order listed (#168 (comment)). That instruction is his approval of this item, including its replacement of the database counters made correct under #56 and the deletion of the tests of the code it removes. Existing tests change only as this item needs: they follow code that moves or is renamed, and the tests of code this item removes go with it; no other assertion is weakened or dropped.
Model: opus-5-5