frontend: alert user if spark is degraded

[bznein]

Before asking for reviews, here is a check list of the most common things you might need to consider:

• updating the Changelog
• writing unit tests
• checking if your changes affect other coins or tokens in unintended ways
• testing on multiple environments (Qt, Android, ...)
• having an AI review your changes

[bznein]

@CodeRabbit review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request adds Spark network status visibility to the Lightning module. The backend introduces a SparkStatus data model with a serviceStatus mapper that converts Breez SDK enums to string labels, and a SparkStatus() method that retrieves status via an injected dependency. A new GET /spark-status HTTP endpoint wires this method into the handlers. The frontend defines TypeScript types to match the response shape and a getSparkStatus() API wrapper, then integrates periodic status polling into the Lightning route component via setInterval, stores the result in state guarded by a mounted ref, adds English localization for status messages, and refactors the UI banner section to conditionally render status-driven warnings alongside the existing alpha warning. Early loading spinners based on balance availability are removed in favor of the existing payment list/spinner logic.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/lightning/lightning_test.go`:
- Around line 99-115: Add a failing-path unit test for Lightning.SparkStatus:
create a Lightning instance whose sparkStatus field is a function that returns
an error (e.g., errors.New("boom")), call lightning.SparkStatus(), and assert
that the returned status is nil and the error matches the injected error (use
require.Error/require.EqualError or require.IsType as appropriate). Ensure the
test name indicates the error path (e.g., TestSparkStatus_Error) and reference
the Lightning struct and its sparkStatus field and the SparkStatus() method when
locating where to add the test.

In `@backend/lightning/lightning.go`:
- Around line 216-218: The raw Breez SDK error is returned directly (return nil,
err), which will bypass our typed error handling in errorResponse(); instead
import and use the backend/util/errp package to wrap/translate the SDK error
before returning (e.g., replace return nil, err with return nil, errp.Wrap(err,
"breez: <brief context>") or return nil, errp.WithCode(errp.CodeX, err) to
assign an appropriate errp code), referencing the same call site in lightning.go
so downstream errorResponse() can perform typed handling.
- Around line 188-223: Add GoDoc comments for the exported type SparkStatus and
the Lightning.SparkStatus method: place a comment starting with "SparkStatus
..." immediately above the type declaring what the struct represents and
documenting its exported fields Status and LastUpdated (units/meaning for
LastUpdated), and place a comment starting with "SparkStatus ..." immediately
above the method func (lightning *Lightning) SparkStatus() describing what the
method returns, under what conditions it can return an error, and any semantics
(e.g., it queries the Spark service via breez_sdk_spark.GetSparkStatus or a test
override). Ensure comments follow GoDoc style (start with the symbol name and
are full sentences).

In `@frontends/web/src/routes/lightning/lightning.tsx`:
- Around line 67-76: The catch block in loadSparkStatus leaves sparkStatus
unchanged on errors, so update the catch to set a safe fallback Spark status
when a poll fails: inside catch, after logging the error, check mounted.current
and call setSparkStatus with a fallback object (e.g., a disabled/unknown state)
so the UI/warning banner reflects the failure; modify the loadSparkStatus
function (the async callback) to perform this fallback update in the catch path.
- Around line 88-92: Replace the hardcoded banner text inside the Status
component with a translation key: import and use the i18n translator (e.g.,
useTranslation / t) and call t('lightning.alphaWarning') (or similar) in place
of the literal string in the Status instance that has
dismissibleKey="lightning-alpha-warning"; then add the corresponding
"lightning.alphaWarning" entry to src/locales/{lang}/app.json for each supported
language with the original message. Ensure the translation key name matches
across the component and locale files.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 82e4eb62-32e1-4242-b95d-696145c0761e

📥 Commits

Reviewing files that changed from the base of the PR and between 2536dc6 and 24a8778.

📒 Files selected for processing (6)

• backend/lightning/handlers.go
• backend/lightning/lightning.go
• backend/lightning/lightning_test.go
• frontends/web/src/api/lightning.ts
• frontends/web/src/locales/en/app.json
• frontends/web/src/routes/lightning/lightning.tsx