AnchorsPanel, SettlementsPanel, and MetricsBar's error states have no retry action, unlike PoolsPanel

[Jagadeeshftw]

📌 Description

When PoolsPanel (src/components/PoolsPanel.tsx) fails to load, it renders the error message plus a "Retry" button that calls its own reload(). AnchorsPanel (src/components/AnchorsPanel.tsx), SettlementsPanel (src/components/SettlementsPanel.tsx), and MetricsBar (src/components/MetricsBar.tsx) each have an equivalent error branch (state.status === "error") but render only the bare error text with no way to retry short of a full page reload — despite AnchorsPanel/SettlementsPanel having a reload/refresh function readily available from useAsync, and MetricsBar having its own refresh from useAsync (already wired to its existing "↻" manual-refresh button, just not reused in the error branch).

🧩 Requirements and context

• Add a retry action to the error state of AnchorsPanel, SettlementsPanel, and MetricsBar, consistent in style/placement with PoolsPanel's existing "Retry" button.
• Each panel should reuse the reload/refresh trigger it already has (reload() for AnchorsPanel, the settlements list's own reload() for SettlementsPanel, refresh() for MetricsBar) rather than introducing a new fetch path.
• No change to the loading or ready states of any of the three components.

🛠️ Suggested execution

• Add a "Retry" button to each component's error branch that calls its existing reload/refresh function, matching PoolsPanel's button styling and label.
• Extend src/components/AnchorsPanel.test.tsx, src/components/SettlementsPanel.test.tsx, and src/components/MetricsBar.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

• AnchorsPanel's, SettlementsPanel's, and MetricsBar's error states each offer a "Retry" action.
• Clicking Retry re-triggers that component's existing fetch without a full page reload.
• Test coverage for the retry action in all three components.

🔒 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

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. I’ll prioritize this immediately and ensure a reliable solution is delivered as soon as possible. Thank you!

[mayborn005]

Hello @maintainer, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me. And I will deliver at the shortest possible time.

[vj570145-web]

Hi maintainer, I'm interested in resolving this issue. I've gone through the description and acceptance criteria and am ready to get started.

[grantfox-oss]

🦊 GrantFox — @vj570145-web has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #283)
2. Your PR will be reviewed by the AnchorNet-Org maintainers

Good luck! Track your progress on GrantFox.

[Jagadeeshftw]

Assigned, @vj570145-web! Go ahead and open a PR referencing this issue when it's ready. Join our group if you have questions: https://t.me/+vTbe0hOUKrFhNTJl