upload.py writes corr_consensus and the corr_llm_* fields (around lines 137 and 151-153), but admin.py:65-93 does not include them in the /admin/debug/correlation response.
Consequence: the one tool built for answering "is the LLM correlation tier actually working" cannot answer it. The 2026-08-19 dump was pulled specifically to check whether the LLM tier had come back to life after the retired-model-ID fix, and the answer had to be inferred from commit dates and field-shape archaeology instead of read off the data.
Given that a dead LLM tier already survived undetected for days once (server-26#14), the debug view not surfacing LLM state is a meaningful gap and a cheap fix.
While in there, two more things the dump showed the endpoint should expose or fix:
corr_incident_idle_min can be negative (-4.1 observed), with the incident's updated_at earlier than its started_at. Something is writing those two timestamps out of order.
Calls with a skip_reason set are linking anyway and then contributing to incident summaries.
Full analysis: CORRELATION_REVIEW_0820.md (project root, not in git).
`upload.py` writes `corr_consensus` and the `corr_llm_*` fields (around lines 137 and 151-153), but `admin.py:65-93` does not include them in the `/admin/debug/correlation` response.
Consequence: the one tool built for answering "is the LLM correlation tier actually working" cannot answer it. The 2026-08-19 dump was pulled specifically to check whether the LLM tier had come back to life after the retired-model-ID fix, and the answer had to be inferred from commit dates and field-shape archaeology instead of read off the data.
Given that a dead LLM tier already survived undetected for days once (server-26#14), the debug view not surfacing LLM state is a meaningful gap and a cheap fix.
While in there, two more things the dump showed the endpoint should expose or fix:
- `corr_incident_idle_min` can be **negative** (-4.1 observed), with the incident's `updated_at` earlier than its `started_at`. Something is writing those two timestamps out of order.
- Calls with a `skip_reason` set are linking anyway and then contributing to incident summaries.
Full analysis: `CORRELATION_REVIEW_0820.md` (project root, not in git).
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.
upload.pywritescorr_consensusand thecorr_llm_*fields (around lines 137 and 151-153), butadmin.py:65-93does not include them in the/admin/debug/correlationresponse.Consequence: the one tool built for answering "is the LLM correlation tier actually working" cannot answer it. The 2026-08-19 dump was pulled specifically to check whether the LLM tier had come back to life after the retired-model-ID fix, and the answer had to be inferred from commit dates and field-shape archaeology instead of read off the data.
Given that a dead LLM tier already survived undetected for days once (server-26#14), the debug view not surfacing LLM state is a meaningful gap and a cheap fix.
While in there, two more things the dump showed the endpoint should expose or fix:
corr_incident_idle_mincan be negative (-4.1 observed), with the incident'supdated_atearlier than itsstarted_at. Something is writing those two timestamps out of order.skip_reasonset are linking anyway and then contributing to incident summaries.Full analysis:
CORRELATION_REVIEW_0820.md(project root, not in git).