📌 Description
PoolsPanel (src/components/PoolsPanel.tsx) renders a "Retry" button in its error branch that calls its own reload(). AnchorDetail (src/components/AnchorDetail.tsx) and SettlementDetail (src/components/SettlementDetail.tsx) each have their own state.status === "error" ? <p className="text-sm text-red-400">{state.message}</p> : (...) branch with no retry action at all — despite both already destructuring a re-fetch trigger from useAsync (reload for AnchorDetail, refresh for SettlementDetail) that they each currently use for exactly one other purpose (re-fetching after a deactivate/execute/cancel action). A user who lands on an anchor or settlement detail page during a transient failure (e.g. a dropped connection) is stuck looking at a bare error message with no way to try again short of a full page reload — the exact gap already identified and planned for AnchorsPanel, SettlementsPanel, and MetricsBar, just not yet extended to these two detail-page components.
🧩 Requirements and context
- Add a retry action to the error state of both
AnchorDetail and SettlementDetail, consistent in style/placement with PoolsPanel's existing "Retry" button.
- Each component should reuse the re-fetch trigger it already has (
reload() for AnchorDetail, refresh() for SettlementDetail) rather than introducing a new fetch path.
- No change to the loading or ready states of either component.
🛠️ Suggested execution
- Add a "Retry" button to the error branch in
src/components/AnchorDetail.tsx (calling reload()) and src/components/SettlementDetail.tsx (calling refresh()), matching PoolsPanel's button styling and label.
- Extend
src/components/AnchorDetail.test.tsx and src/components/SettlementDetail.test.tsx with a test per component that triggers the error state, clicks "Retry", and asserts the underlying fetch function is called again.
✅ Acceptance criteria
🔒 Security notes
No new attack surface; reuses each component's already-existing, already-authorized fetch path.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
PoolsPanel(src/components/PoolsPanel.tsx) renders a "Retry" button in its error branch that calls its ownreload().AnchorDetail(src/components/AnchorDetail.tsx) andSettlementDetail(src/components/SettlementDetail.tsx) each have their ownstate.status === "error" ? <p className="text-sm text-red-400">{state.message}</p> : (...)branch with no retry action at all — despite both already destructuring a re-fetch trigger fromuseAsync(reloadforAnchorDetail,refreshforSettlementDetail) that they each currently use for exactly one other purpose (re-fetching after a deactivate/execute/cancel action). A user who lands on an anchor or settlement detail page during a transient failure (e.g. a dropped connection) is stuck looking at a bare error message with no way to try again short of a full page reload — the exact gap already identified and planned forAnchorsPanel,SettlementsPanel, andMetricsBar, just not yet extended to these two detail-page components.🧩 Requirements and context
AnchorDetailandSettlementDetail, consistent in style/placement withPoolsPanel's existing "Retry" button.reload()forAnchorDetail,refresh()forSettlementDetail) rather than introducing a new fetch path.🛠️ Suggested execution
src/components/AnchorDetail.tsx(callingreload()) andsrc/components/SettlementDetail.tsx(callingrefresh()), matchingPoolsPanel's button styling and label.src/components/AnchorDetail.test.tsxandsrc/components/SettlementDetail.test.tsxwith a test per component that triggers the error state, clicks "Retry", and asserts the underlying fetch function is called again.✅ Acceptance criteria
🔒 Security notes
No new attack surface; reuses each component's already-existing, already-authorized fetch path.
📋 Guidelines