fix: domains.py signing-identity resolution uses resolved hub URL (muse#20)
Scope: muse-repo phases only (1, 2, 4). Phase 3 (musehub's legacy proposalType values — state_merge etc. — needing a rename migration) lives entirely in the musehub repo's own Alembic migrations/service layer/MCP tools and is explicitly out of scope here; flagged in the closing comment for separate musehub-side tracking.
Phase 1 — domains.py bug (muse repo): run_publish/run_update/run_delete all compute resolved_hub (from --hub, the repo's [hub] url, or the musehub.ai default) but then called get_signing_identity(repo_root) without forwarding it — the identity lookup silently fell back to the repo's default hub host instead of the actual target whenever --hub pointed somewhere else. Same bug class as the ls-remote HTTP 401 this ticket's background section describes (already fixed in an earlier session, feat/test-merge-6). The ticket named one occurrence (~line 796-800 in an older revision); the audit found three — all three call sites (publish/update/delete) had the identical bug. Fixed by forwarding remote_url=resolved_hub at all three.
Phase 2 — release.py call style (muse repo): Normalized three get_signing_identity(root, url) positional calls to get_signing_identity(root, remote_url=url) explicit-keyword style. No behavior change (positional order was already correct) — makes the intent auditable and guards against future positional-arg drift in get_signing_identity's signature silently breaking identity resolution.
Phase 4 — cross-host regression guard (muse repo): New tests/test_cross_host_signing_identity.py: a repo whose default [hub] url and a named "staging" remote deliberately point at different hostnames, driving ls-remote, fetch, and domains publish (the three callers the ticket names) against the named remote, asserting each resolves identity against the remote's own hostname — not the default hub's. Mocked transport/network, no live hub required (unlike the existing tests/test_wire_localhost.py, which only runs against a real running localhost:1337 and auto-skips otherwise). This is the regression guard the ticket asks for: any future command that computes a target URL but forgets to forward it to get_signing_identity will fail this test immediately.
Also: tests/test_domains_signing_identity.py — one regression test per fixed call site (publish/update/delete) plus one for release.py's call-style normalization, following the TestSigningIdentityForwarding pattern already established in tests/test_cmd_ls_remote.py.
Confirmed genuine RED by reverting domains.py + release.py together and re-running: all 4 test_domains_signing_identity.py tests failed with remote_url=None instead of the expected target host — restored, all green. Separately confirmed the new cross-host guard correctly turns red when only domains.py's fix is reverted (ls-remote/fetch stay green since they were already correct per the ticket's own audit) and green again restored.
Regression: 703 tests across domains, release, and ls-remote test suites — all green, no regressions.
Semantic Changes
42 symbols
Files Changed
+2
~2
1258 in snapshot
0 comments
muse hub commit comment sha256:c5d88af19bcd6c1e60fd829dea85a4fdd5a74f74c5617031ba5b2955ba6a5b95 --body "your comment"
No comments yet. Be the first to start the discussion.