gabriel / muse public
Closed #30 Bug
filed by aaronrene human · 41 days ago · assigned to gabriel

staging gabriel/muse repo has blobs missing from storage — clone/pull and raw reads fail

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Summary

The gabriel/muse repo on staging has blob objects missing from storage. Any muse pull / muse clone that reaches those objects fails, and direct raw-file reads return a 404-style error from the server. This blocks contributors from cloning the repo and updating the CLI to rc11.

Reproduction

Client-side (rc10, but server-confirmed — no client quirk)

muse pull   # or: muse clone https://staging.musehub.ai/gabriel/muse

Fetches 1 230 commits then fails:

head commit sha256:c5131d76… unreadable / working tree not restored

Server-side confirmation (no client involved)

GET https://staging.musehub.ai/gabriel/muse/raw/main/pyproject.toml

Response:

{"detail":"File 'pyproject.toml' found in manifest but missing from storage (object sha256:9106803df…)"}

Same error for: LICENSE, CLAUDE.md, .museignore, docs/reference/porcelain.md.

README.md serves fine (its blob is present).

Root cause hypothesis

Pre-rc11 object drops caused by the object_refs / mpack_index bug that rc11 fixed. The affected objects were never backfilled after the fix landed, leaving gaps in the gabriel/muse object store on staging.

Ask

Either:

  1. Re-push muse main from your local store — the rc11 repush fix should restore the dropped objects and backfill the gaps.
  2. Publish an rc11 release tarball so contributors can install rc11 via the release page without needing a working clone first.

This currently blocks contributors from updating to rc11.

◎ Activity2
●
aaronrene opened this issue 41 days ago
○
gabriel 41 days ago

re-pushing main from a local store with the rc11 repush fix backfilled the missing objects

✓
closed this issue 41 days ago
○
aaronrene 41 days ago

rc11 follow-up: clone no longer crashes, but still materializes an empty repo

Re-tested after installing Muse CLI 0.2.0rc11 from the staging installer (muse --version confirms muse 0.2.0rc11). The original missing-blob crash path is guarded now, but muse clone / follow-up muse pull still do not functionally complete for gabriel/muse on staging.

Reproduction

rm -rf /tmp/muse-rc11-clonetest
cd /tmp
muse clone https://staging.musehub.ai/gabriel/muse muse-rc11-clonetest
cd /tmp/muse-rc11-clonetest
muse status
muse log
muse pull origin main

Observed

Clone exits 0, but writes zero commits and zero snapshots, and does not restore the working tree:

[clone] apply_mpack START  blobs=99 commits=1325 snaps=1303
⚠️ apply_mpack: snapshot sha256:ef2ecaf5098e7 hash mismatch (reconstructed=sha256:be9d5d3870b85) — skipped
...
⚠️ apply_mpack: commit sha256:78c1b9e061a3 skipped — snapshot sha256:1b8f5633e00c was not in this mpack and is not in the local store (server sent snaps=0). The next pull will re-request this commit with its snapshot.
⚠️ apply_mpack: commit sha256:18e585c043b10139697a2d40412cf49b2efd39ac6366827a41299037fc915f4c skipped — parent not in mpack or local store
[clone] apply_mpack DONE  t=284ms  blobs_written=99 blobs_skipped=0  commits_written=0
[mpack] fetch/mpack: 33.48s  blobs: 99  commits: 0
[clone] apply_manifest START  (working tree restore)
⚠️ clone: commit sha256:53386fd8a81ed8223bf9274bfbc201141ea13cfe6bc6dfb154aace6a787d2276 not found after apply_mpack — working tree not restored
[clone] apply_manifest DONE  t=0ms
✅ Cloned into 'muse-rc11-clonetest' — 0 commit(s), 99 blob(s), domain=code, branch=main (sha256:53386fd8a81ed8223bf9274bfbc201141ea13cfe6bc6dfb154aace6a787d2276)

Post-clone state:

muse status
# On branch main
# Your branch is up to date with 'origin/main'.
# Nothing to commit, working tree clean

muse log
# (no commits)

.muse/refs/heads/main -> sha256:53386fd8a81ed8223bf9274bfbc201141ea13cfe6bc6dfb154aace6a787d2276
.muse/commits count -> 0
.muse/snapshots count -> 0
top-level working tree entries -> only .muse

Follow-up pull does not recover the skipped commit/snapshot state:

muse pull origin main
Already up to date.
✅ Fetched 0 commit(s), 0 new blob(s) from origin/main (sha256:53386fd8a81ed8223bf9274bfbc201141ea13cfe6bc6dfb154aace6a787d2276)

post-pull:
commits=0
snapshots=0
working tree still empty

Expected

A successful clone of gabriel/muse should materialize the commit DAG, snapshots, and working tree. If the server sends unusable snapshots, the command should not report a successful completed clone with “up to date” status while the local repo contains no commits.

Gate impact

This is independent of the private-repo visibility fix (#87), which returned non-200 on all unauthenticated SSR/raw probes. It still blocks rc11_backfill_confirmed for downstream private-repo staging gates: staging object-store integrity is not proven while fresh clone/pull returns an empty repository.