Record the hits-v1 fingerprint as PENDING, and why

The prod-write fingerprint did not land: the odds provider is returning 429
(quota exhausted), so the snapshot refuses with gradeCount 0 and the MLB board
has been frozen since 07:30 UTC. The 14/19/22 UTC cron slots failed the same
way, all before this change deployed -- hits-v1 sits inside the snapshot's
existing try/catch, is purely additive, and had zero grades to attach to.

Firing is already verified against the real production snapshot through the
real attachProjection path (158/159). What is pending is only confirmation
that the deployed process writes the columns, which needs a slate the pipeline
can fetch. The exact fingerprint query is recorded in the spec.

The odds quota exhaustion is a live outage of the whole grading pipeline and
is flagged for its own order, not folded into this one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W1sivYNqY2TS5ftykmHBU9
This commit is contained in:
Kev
2026-08-02 19:07:58 -04:00
parent 07626de3de
commit 2394fb04a1
+45
View File
@@ -293,3 +293,48 @@ Supabase project ref (`zmdnczhtdxcddszxttub`; the real ref is
unaffected — the deployed API and the MCP connection both use the correct ref.
The holdout was run with an explicit `SUPABASE_URL` override rather than editing
your credentials file.
## 11. POST-DEPLOY FINGERPRINT — armed, PENDING (blocked upstream, not by this change)
Deployed 2026-08-02 ~23:05 UTC (the API 502'd and returned at 23:05:35, right
after the push). The **prod-write fingerprint has NOT landed yet**, and the
reason is upstream of this work:
```
POST /api/internal/snapshot/mlb -> {"status":"error","gradeCount":0,
"reason":"Odds data temporarily unavailable"}
GET /api/odds/mlb -> HTTP 429
GET /api/internal/snapshot/status -> overdue: true, mlb last 2026-08-02T07:30:46Z
```
**The odds provider is quota-exhausted (429), so the pipeline cannot grade a
slate at all.** The MLB board has been frozen since 07:30 UTC and the 14/19/22
UTC cron slots all failed the same way — every one of them before this change was
deployed. hits-v1 is inside the snapshot's existing try/catch and is purely
additive; it cannot be the cause, and there were zero grades for it to attach to.
If PropLine's quota resets at 00:00 UTC, the 01:00 UTC cron slot should be the
first successful run. The fingerprint to confirm hits-v1 is writing in prod:
```sql
select count(*) rows_today,
count(proj_hits_p_over) hits_v1_written,
round(avg(proj_hits_p_over)::numeric, 3) mean_p,
count(*) filter (where proj_hits_meta->'market'->>'market_takeable' = 'true') takeable,
count(*) filter (where proj_hits_meta->'market'->>'within_promotion_band' = 'false') outside_band
from public.ledger_entries
where sport = 'mlb' and user_id is null and stat = 'hits'
and graded_at > now() - interval '6 hours';
```
Expected on a healthy run, from the live-board verification in §7: `hits_v1_written`
at roughly 99% of `rows_today`, and a substantial `outside_band` count that was
modelled anyway.
**Firing itself is already verified** — §7 ran the production `attachProjection`
over the real production snapshot payload and got 158/159. What is pending is
only the confirmation that the deployed process writes the columns, which needs a
slate the pipeline can actually fetch.
**Flagged for its own order, out of scope here:** the odds quota exhaustion is a
live production outage of the whole grading pipeline, not a hits problem.