The `cache_*` SEMCONV families report 0 in a default deployment because nothing unconditionally consumes the `cache` service — a zero there reads as "no cache activity", not "not exercised"

[huangyiirene]

Found while implementing #9832 (PR #9951), which wires observability:metrics so the cache adapter finally receives the host's configured registry. Filed unassigned; not graded by the filing seat. Out of #9832's scope — that card's job was the wiring, and the wiring works.

The measurement, on d637847b79 (branch point 45862a53d)

After #9832's fix the cache adapter demonstrably holds the real registry. Booting the showcase app through the real serve.ts with OS_OBS_EXPORTER=console --log-level info:

CacheServicePlugin: registered memory cache adapter (metrics=ConsoleMetricsRegistry)

(the same line reads metrics=NoopMetricsRegistry on the parent commit).

And yet cache_lookups_total, cache_writes_total and cache_errors_total all emitted 0 across a full probe sequence: discovery, a successful sign-in, three authenticated REST data reads, a presigned upload plus the real PUT, and 25 rapid failed sign-ins aimed specifically at the rate limiter.

Why — the cache service has no unconditional consumer

Swept repo-wide for resolutions of the service (packages/, apps/, excluding dist/ and tests). Every production consumer is conditional on operator configuration:

• packages/plugins/plugin-auth/src/auth-plugin.ts:424 — better-auth rate-limit counters, via createLazyCacheRateLimitStorage. auth-plugin.ts:1373 only sets rateLimit.enabled when an operator explicitly supplies rate_limit_max or rate_limit_window_seconds in settings, so the counter is never consumed in a default install.
• packages/services/service-sms/src/sms-plugin.ts:125 — the per-number OTP send budget, reached only on an SMS send path.

The remaining hits are the plugin's own JSDoc, packages/core/examples/, and packages/lint/src/lint-startup-registry-verdict.ts prose. No unconditional reader exists.

Why it is worth recording

This is the hazard #9650's ruling named in as many words for the HTTP family: a zero on an instrumented surface must mean "no traffic", never "not instrumented". The cache_* families are declared in SEMCONV as a stable namespace explicitly "so hosts can wire alerts/dashboards against it", and an operator who builds a cache hit-rate panel against cache_lookups_total gets a flat zero that is indistinguishable from a cache that is never consulted — which, here, is the literal truth, but not one the metric name communicates.

Two readings, and grading has to pick:

1. The families are correct and the platform genuinely does not use its own cache service on hot paths — in which case the finding is really about the cache service being near-dead weight in the default slate, and the metric is honest.
2. The platform should be consulting the cache on paths that currently do not (metadata resolution, permission lookups) — in which case the flat zero is a symptom, not the defect.

I did not attempt to resolve which; that judgement is outside what #9832 measured.

Not claimed here

• Nothing about whether the adapter emits correctly when it is exercised: PR fix(cli): serve registers ObservabilityServicePlugin so observability:metrics resolves for every consumer (#9832) #9951's pin drives a real lookup through the resolved service and observes cache_lookups_total{adapter=memory,result=miss}, so the emission path itself is fine.
• No claim about storage_*, which does have an unconditional consumer and was measured emitting live in the same session.

Dedup

search_issues returned 0 hits for the cache-metric phrasing, with a passing control (the same tool found #9650 for a neighbouring query in the same minute), so the zero is a real no-duplicate rather than the tool being down.

---

Generated by Claude Code