gabriel / musehub public
Closed #198 Bug
filed by gabriel human · 34 days ago

Files Changed panel shows '1,068 of 0' and marks repo fully deleted despite 0% divergence and all files present

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Summary

#144's merge proposal page's "Files Changed" panel reads 1,068 of 0 and marks the whole repository as deleted — but the same page reports 0% divergence, and ls-tree -r 8a1389ae confirms all 1,068 files are actually present.

Why this matters

Purely a display bug — the underlying merge/data is correct — but it's a dangerous one. A reviewer trusting the panel at face value would reasonably conclude the MP nukes the entire codebase and reject or panic over a perfectly good merge.

Suggested investigation

Likely a denominator bug in whatever computes the "X of Y" files-changed count — Y is coming back as 0 (perhaps an empty/missing base-manifest count) while X (1,068) is correct, and the UI's "of 0" plus zero-files-remaining is being interpreted downstream as "entire repo deleted."

  • #144 — the feature ticket whose MP surfaced this display bug.

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

Fixed and deployed to staging and production.

Root cause: proposal_detail_page (musehub/api/routes/musehub/ui_proposals.py) resolved the Files Changed diff's snapshot IDs via live MusehubBranch name lookups. Once a proposal's source branch is deleted — routine post-merge cleanup — that lookup returns None, the 'new' manifest is empty, and get_snapshot_diff misreports the entire base manifest as removed, with a denominator of 0 ('X of 0') — looking like the merge wiped the repo.

Fix: for a merged proposal, anchor the diff to proposal.merge_commit_id's own recorded lineage — the merge commit's snapshot vs. its parent's snapshot — instead of re-resolving branch names. This mirrors the pattern ui_commits.py's diff_page already uses for ordinary commits, and is immune to branch deletion since it never re-resolves anything by name. Open (unmerged) proposals keep the original live-branch-lookup behavior.

Tests: new TestFilesChangedPanelAfterMerge in tests/test_musehub_ui_proposal_ssr.py — a real end-to-end HTTP GET against a merged proposal with a deleted source branch, confirmed RED before the fix and GREEN after. Full regression sweep across the proposal/merge/repo/wire-fetch suites: 236 passed, no regressions.

Filed a separate follow-up for something unrelated found along the way: the '% divergence' figure on this same page is a hardcoded stub that never reflects real branch state — out of scope for this ticket, tracked separately.

✓
closed this issue 34 days ago