analytics (systemic): the empty-cache/slow-analyze pattern spans 6+ modules (bug-prediction, security-score, anti-pattern, dependencies, duplicates, import-tree) — every /cached is empty; anti-pattern/cached 500s #12365

Summary

The dual-mechanism pattern documented for Codebase Analytics in #12364 is not local to that module — it is the shared shape of the whole analytics / code-intelligence surface. At least six independent modules each expose an analyze (live, slow) + cached (read a store) + status triad, and on the deployed instance every one of the /cached endpoints is empty or erroring — because nothing auto-populates the store. The result is the same everywhere: panels render blank, or trigger a multi-second-to-timeout live analysis.

The pattern

Each of these modules is built as "compute live on demand, and separately read a cache that some manual/absent job was supposed to fill":

Every /cached path returns nothing usable. The stores are never populated because, as with codebase analytics (#12364), population is a manual/uninvoked step — no module auto-indexes on source registration, and the live analyze endpoints do not write back to the cache the cached endpoints read.

Why this matters

For a user, opening any of these panels does one of two things: shows an empty/"no data" state, or kicks off a live analysis that takes 10 s–timeout. There is no third path where a populated cache serves a fast result, because nothing fills the cache. The feature looks like it has a fast cached tier and a slow compute tier; in practice only the slow tier ever runs.

This is the same unmade design decision as #12364 and the same canonical fork as #12362, replicated across the analytics surface: the "index once, read fast" pipeline was scaffolded (the /cached and /status endpoints exist) but never wired to actually populate or auto-refresh.

Distinct sub-bug: anti-pattern/cached returns 500

Unlike the others that degrade to a clean no_data, GET /api/anti-pattern/cached throws:

$ curl -sk /api/anti-pattern/cached -H "Authorization: Bearer <token>"
{"detail":"Failed to retrieve cache"}      # HTTP 500

A cache-miss should be a no_data 200, not a server error. This one additionally fails ungracefully — the panel gets a 500 instead of an empty state, so it cannot even show "no data yet." Worth fixing independently of the systemic design work.

Recommendation (architecture — needs owner sign-off)

Treat this as one decision applied across all six modules, not six fixes:

1. One populate-and-refresh pipeline. When a source is indexed, populate every analyzer's cache (bug-prediction, security-score, anti-pattern, dependencies, duplicates, import-tree) as part of that job, and invalidate on re-index. This is the convergence proposed in analytics root cause: Codebase Analytics runs on two non-shared data mechanisms (indexed store vs live filesystem walk) — explains empty panels, cross-project leak (#12330), and 10-279s latency (#12341) as one problem #12364, generalised.
2. Until then, /analyze endpoints should write their result into the same store /cached reads, so at least the second viewer gets a fast path.
3. Fix anti-pattern/cached to return no_data (200) on a miss rather than 500.
4. A single shared test — "for a freshly indexed source, every /cached endpoint returns populated, source-scoped data" — would cover all six and prevent regression. The current environment (single source, never indexed) hides every instance.

Discovery/synthesis issue, filed per the marketing-session rule (expose, do not fix). Extends #12364 from one module to the surface; related to #12341 (latency), #12330 (scoping), #12362 (the underlying fork).

Environment

install.sh deploy at /opt/autobot; deployed tree matches origin/Dev_new_gui. All /cached responses captured live against the running backend, source f5673506-….