fix(ui): distinguish a failed related-Multisig-calls fetch from an empty result

[davion-knight]

What

The "Related Multisig calls" section computed relatedCalls from a useQuery with no isError branch. A genuine fetch failure leaves data undefined, so relatedCalls becomes [] and the section rendered:

No other extrinsics reference this call_hash yet.

— asserting a fact the app doesn't actually know. Every other secondary query on the sibling accounts.$ss58.tsx page checks isError and renders TableState variant="error" with retry; this one now does too.

The branch order is the fix: isLoading → isError → rows → empty, so the empty copy is only reachable when the fetch genuinely succeeded with zero rows (the issue's second requirement).

Proof — the error state, forced

Screenshots can't show this fix: on a healthy page the fetch succeeds, so before and after are identical. So I forced it, aborting only the related-calls lookup (it's the only request carrying call_hash=; the extrinsic detail itself stays healthy — exactly the scenario the issue describes):

	behaviour when the related-calls fetch fails
before	❌ "No other extrinsics reference this call_hash yet." — indistinguishable from a real empty result
after	✅ "Couldn't load related Multisig calls" + retry

Both still render the section, and both aborted the same 4 requests.

Screenshots

/extrinsics/0x25a23bcd… at #multisig-chain, showing the section in its successful empty state — identical before/after, since the new branch only renders on failure.

One note on picking that extrinsic: the section only renders when multisigCallHash() resolves, and as_multi calls here carry a nested decoded call with no call_hash — so they render no section at all. approve_as_multi carries call_hash directly, which is why this hash was used.

Viewport · Theme	Before	After
Desktop · Light	before	after
Desktop · Dark	before	after
Tablet · Light	before	after
Tablet · Dark	before	after
Mobile · Light	before	after
Mobile · Dark	before	after

Testing

extrinsics-multisig-error.test.ts (5 tests) — source assertions (this section lives in a route needing a router and live data; the suite is node-environment, and the repo tests this way in ui-kit's list-shell.test.ts):

• an isError branch exists for the related-calls query;
• it renders variant="error" with error={relatedQuery.error} and a refetch retry, per the accounts.$ss58.tsx pattern;
• isError is checked before the empty copy — asserted by index, since a branch that exists but sits after the empty case would still let a failure fall through;
• isLoading stays ahead of both, so a pending fetch isn't reported as an error;
• the empty copy still exists — it's made unreachable on failure, not removed.

Verified meaningful: 4 of the 5 fail against the upstream file (the 5th passes both ways by design — it asserts the empty copy survives).

apps/ui: 141 files / 1065 tests pass, tsc clean, eslint 0 errors, format:check clean. Diff is 2 files, both under apps/ui/src.

Closes #6426

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.85%. Comparing base (632d986) to head (c2b340a).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6501   +/-   ##
=======================================
  Coverage   97.85%   97.85%           
=======================================
  Files         174      174           
  Lines       22196    22196           
  Branches     8798     8798           
=======================================
  Hits        21721    21721           
  Misses         81       81           
  Partials      394      394           

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-17 12:40:51 UTC}

2 files · 1 AI reviewer · no blockers · CI green · clean

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review: This PR changes guardrail-protected path(s): apps/ui/src/routes/extrinsics.$hash.tsx (matched apps/ui/**), apps/ui/src/routes/extrinsics-multisig-error.test.ts (matched apps/ui/**).

Review summary
Adds an isError branch to the related-Multisig-calls query so a failed fetch renders a TableState error with retry instead of falling through to the empty-result copy, matching the isError pattern used elsewhere (e.g. accounts.$ss58.tsx). Branch ordering (isLoading → isError → rows → empty) correctly makes the empty message reachable only on genuine success, which is the actual bug fix. The added test is source-string based rather than a render test, but that mirrors an existing repo convention noted in the PR description and is reasonable for a route requiring router context.

Nits — 4 non-blocking

• The test in extrinsics-multisig-error.test.ts asserts against raw source-code substrings/positions rather than rendered behavior, so it can pass even if the JSX is logically broken in ways that preserve string order — consider a lightweight render/unit test of the branch logic if the router dependency can be mocked.
• The inline comment referencing extrinsics.$hash.tsx's "Related Multisig calls" section silently treats a fetch error as "no related calls" #6426 and the accounts.$ss58.tsx convention is helpful but slightly verbose for a one-line branch; could be trimmed.
• Consider extracting the isLoading/isError/rows/empty branching pattern (repeated across accounts.$ss58.tsx and now extrinsics.$hash.tsx) into a shared helper/component to avoid future copy-paste of the same four-way branch.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ⚠️ Gate result — Not blocking (Advisory; not blocking this PR.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6426
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 192 registered-repo PR(s), 122 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	davion-knight; Gittensor profile; 192 PR(s), 0 issue(s).

Linked issue satisfaction

Addressed
The diff adds an isError branch to the multisig-chain section that renders TableState variant="error" with retry, correctly ordered before the empty-result branch so the empty copy only shows on genuine zero-row success, matching both stated requirements.

Review context

• Author: davion-knight
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Rust
• Official Gittensor activity: 192 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Triage stale or unlinked PRs.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/	desktop	before /	after /	—
/	mobile	before / (mobile)	after / (mobile)	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver closed this because @davion-knight has 3 open pull requests, above this repository's configured limit of 2. Close or merge an existing one to open a new one. This is an automated maintenance action.