[GH-ISSUE #1364] content-hash SLI mismatch on 2026-04-17T06:59:09.220Z #4387

New Issue

GiteaMirror · 2026-04-19T12:24:29-05:00

GiteaMirror commented

2026-04-19 12:24:29 -05:00

Originally created by @github-actions[bot] on GitHub (Apr 17, 2026).
Original GitHub issue: https://github.com/harvard-edge/cs249r_book/issues/1364

Hourly sampling detected a content_hash mismatch between the production Worker and the release vault.db. This is a data-plane SLI alert — corpus content may be corrupted at the edge. Workflow: https://github.com/harvard-edge/cs249r_book/actions/runs/24552271117

Originally created by @github-actions[bot] on GitHub (Apr 17, 2026). Original GitHub issue: https://github.com/harvard-edge/cs249r_book/issues/1364 Hourly sampling detected a content_hash mismatch between the production Worker and the release vault.db. This is a data-plane SLI alert — corpus content may be corrupted at the edge. Workflow: https://github.com/harvard-edge/cs249r_book/actions/runs/24552271117

GiteaMirror added the vault-sli bug priority-high labels 2026-04-19 12:24:29 -05:00

GiteaMirror closed this issue

2026-04-19 12:24:31 -05:00

GiteaMirror commented

2026-04-19 12:24:32 -05:00

@profvjreddi commented on GitHub (Apr 17, 2026):

Closing as stale / duplicate. Root cause: the vault-content-hash-sli workflow's Python probe threw ValueError: unknown url type before any hash compare step because WORKER_URL was unset (worker not yet deployed). The issue title ("content-hash SLI mismatch") was misleading — there was no mismatch, only an infra-config failure dressed as data corruption.

Fixed in #1384 by deleting the workflow outright rather than patching it. The SLI's design conflated build-output consistency with runtime integrity; the compiler's atomic write already provides the invariant it claimed to check. If runtime integrity becomes a real requirement later, the right architecture is signed responses + client verification, not hourly hash re-probing.

No new content-hash SLI mismatch issues should auto-file after this point.

@profvjreddi commented on GitHub (Apr 17, 2026): Closing as stale / duplicate. Root cause: the `vault-content-hash-sli` workflow's Python probe threw `ValueError: unknown url type` before any hash compare step because `WORKER_URL` was unset (worker not yet deployed). The issue title ("content-hash SLI mismatch") was misleading — there was no mismatch, only an infra-config failure dressed as data corruption. Fixed in #1384 by deleting the workflow outright rather than patching it. The SLI's design conflated build-output consistency with runtime integrity; the compiler's atomic write already provides the invariant it claimed to check. If runtime integrity becomes a real requirement later, the right architecture is signed responses + client verification, not hourly hash re-probing. No new `content-hash SLI mismatch` issues should auto-file after this point.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/cs249r_book#4387