gabriel / musehub public
Closed #54
filed by aaronrene human · 156 days ago · assigned to gabriel

Bug: muse hub proposal merge fails with API 422 — limit=200 exceeds server max of 100

0 Anchors
— Blast radius
— Churn 30d
0 Proposals

Summary

muse hub proposal merge fails with a 422 validation error regardless of merge strategy. The merge endpoint is internally making a list/pagination request with limit=200, which exceeds the server's maximum of 100.

Steps to reproduce

muse hub proposal merge sha256:<any-valid-proposal-id> --strategy squash
# also fails with --strategy merge_commit and --strategy rebase

Error

❌ MuseHub API error 422: [{'type': 'less_than_equal', 'loc': ['limit'], 'msg': 'Input should be less than or equal to 100', 'input': 200, 'ctx': {'le': 100}}]

Environment

  • muse version: 0.2.0rc7
  • repo: aaronrene/knowtation (public, 634+ files)
  • proposal: sha256:7eabc33fd0dff23f2e78769b167b29de18dbd230cac3972527c98129e95bc596
  • all three strategies fail identically

Root cause hypothesis

The merge endpoint internally calls a list API (possibly to walk commits or files in the snapshot) with a hard-coded or default limit=200. The server-side Pydantic model caps limit at 100. The fix is either to lower the client-side default to ≤100 or to raise the server-side cap.

Impact

Proposal merges are completely blocked via CLI. This is a blocker for any team using the MuseHub-first workflow — proposals can be created and reviewed but not merged.

Workaround

None available via CLI. Merging must be done through the MuseHub UI if a merge button is available there, or by bypassing proposals and committing directly to main (which defeats the proposal workflow).

◎ Activity1
●
aaronrene opened this issue 156 days ago
○
gabriel 103 days ago

Already fixed — the root cause and fix live in the muse CLI repo, not MuseHub server code.

Root cause: _resolve_proposal_id() (muse/cli/commands/hub/__init__.py) checked for a full proposal ID by testing for a hyphen, so a sha256:-prefixed ID always fell through to the proposals-list endpoint with ?limit=200 — and the server's Pydantic model caps limit at 100, producing the 422 on every merge regardless of strategy.

Fix: _resolve_proposal_id now calls split_id() first — a sha256:/blake3:-prefixed full ID is recognized and returned as-is with no network round-trip at all, so the list endpoint (and its limit constraint) is never hit on that path. Legacy hyphenated UUIDs and short prefixes still resolve via the list, unchanged.

Verified: TestResolveProposalIdSha256Passthrough and TestProposalMerge422Regression in tests/test_cmd_hub_hardening.py (5 tests) all pass, including a direct regression test asserting run_proposal_merge with a full sha256 ID makes no list call at all. This is already merged and live on muse's dev branch — closing as resolved. If this is still reproducing on a specific muse CLI version, it likely predates this fix; please reopen with the exact muse --version output if so.

✓
closed this issue 103 days ago