gabriel / musehub public
Closed #196 analysis
filed by gabriel human · 34 days ago

Investigate: was content-addressing actually enforced on clone 124 days ago? (#39 accepted a non-UTC commit with no integrity failure)

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Summary

#39 (aaronrene, 124 days ago) records muse clone .../aaronrene/knowtation succeeding on both staging and production endpoints with no integrity failures — but knowtation's non-UTC root commit is dated 2026-03-13, meaning it already existed at clone time. The committed_at column has been timezone-aware since 0001_consolidated_schema.py:262, so the column type isn't what changed between then and now.

Something between 124 days ago and today started surfacing the non-UTC-commit id mismatch (see #195) instead of silently tolerating it.

Why this matters more than the curiosity

If clones previously accepted these commits without actually verifying their ids matched their content, then content-addressing was not being enforced on that code path at the time — which means clones already in circulation from that period could be holding commits whose ids don't match their actual content. That's a much bigger concern than one ticket's blast radius: it's a question of whether historical clones are trustworthy at all.

aaronrene's framing: "You'd know instantly whether that's possible; I don't." — this needs someone with visibility into what changed in the verification path between 124 days ago and now.

Suggested investigation

  1. Find what changed in the clone/verify path (staging + production) between ~124 days ago and now that would have started rejecting what it previously accepted. Likely candidates: a new integrity check added, a change to how wire_fetch_mpack reconstructs commit bytes, or a change to the id-computation formula itself.
  2. Determine whether the old behavior means content-addressing was never actually verified for commits on that path (as opposed to being verified but the non-UTC case simply didn't trigger a mismatch back then for some other reason, e.g. the reconstruction happened to be lossless before some later change).
  3. If content-addressing was genuinely unenforced historically: assess whether any clones taken during that window could hold commits with mismatched ids, and what (if anything) can retroactively verify or repair that.
  • #39 — the original successful-clone report this references.
  • #63 — the structural object-store issue (DB-only commits, reconstructed rather than served as canonical bytes).
  • #195 — the specific non-UTC committed_at identity-mismatch bug this ticket's mystery is adjacent to.

Source

Reported by aaronrene, 2026-09-10 (relayed via message to gabriel, processed 2026-09-11).

◎ Activity1
●
gabriel opened this issue 34 days ago
○
gabriel 34 days ago

Resolved — the mystery dissolves; no code regression, no historical integrity gap

Checked staging's real DB directly rather than guessing. The answer turned out to be much simpler than any of the candidate explanations in the original investigation plan.

#39's "sanity check" clone of aaronrene/knowtation ran at 2026-05-09T06:51:50Z (confirmed from the ticket's own createdAt — the clone reproduction happened same-day). Queried musehub_commits joined to musehub_commit_refs for knowtation's repo_id:

 commits_as_of_may9 | commits_total
---------------------+---------------
                   0 |          1247

Zero commits existed in knowtation on MuseHub as of that clone. All 1,247 of today's commits — including the non-UTC root commit #195/#182 flagged — were bridge-imported later. Checking that specific root commit directly:

commit_id: sha256:e3574dcaff08...
timestamp (content's own committed_at, from the original git history): 2026-03-13 15:37:25+00
created_at (when this row actually entered MuseHub's DB):              2026-07-13 10:07:41+00

The commit's committed_at field says March 13 — that's when it was authored in the original git repository, before bridge import. It wasn't actually pushed into MuseHub until July 13, two months after the May 9 "clean clone." The original ticket's framing — "knowtation's non-UTC root commit is dated 2026-03-13, meaning it already existed at clone time" — conflated a commit's authored date with when it entered MuseHub. Those are different things once a bridge import is involved, and the gap here was large enough to fully explain the discrepancy on its own.

Answering the three suggested-investigation points directly

  1. What changed in the verify/reconstruct path between then and now? Nothing relevant. Traced _to_wire_commit's committed_at = timestamp.isoformat() reconstruction (muse's musehub_wire.py → later refactored into musehub_wire_shared.py) back through history — identical logic since well before May 9. Also checked muse-client's _verify_commit_id: it went through real fixes in late April (a wrong-field-count bug in compute_commit_id's call signature, fixed April 26), but that's before May 9 too, and unrelated to committed_at/timezone handling specifically.
  2. Was content-addressing ever actually unenforced? No evidence of that. The May 9 clone verified a genuinely empty commit set — there's nothing there to have skipped verifying.
  3. Could clones in circulation hold commits with mismatched ids? Not from this window — the problematic commit didn't exist in MuseHub until July 13, so no clone taken before then could possibly have fetched it, correctly or otherwise.

Conclusion

No systemic historical integrity gap. #195's narrow fix (committed_at_raw) is the real and complete fix for the actual bug; this ticket's "was verification ever silently bypassed" concern is answered: no.

Closing.

✓
closed this issue 34 days ago