Make /system/health unauthenticated, compute real readiness from the
shared startup state via build_health_info, and return 503 (body still a
SystemHealthInfo) when a subsystem is not ready. Drop the now-dead
per-backend get_system_health delegation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
build_health_info maps the startup state to SystemHealthInfo (platform
independent, pure, synchronous). Rename SubSystemHealthInfo.health ->
healthy to match the top level, and switch the two health models from
the misused Query() to Field().
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Move the in-process startup-state singleton out of app.main into
app.api.startup_status so app.system can read it without a circular
import. No behavior change - main mutates the same shared object.
Also lands the design spec and implementation plan for the
system/health endpoint work (#145).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Route HTTPException (app- and framework-raised), RequestValidationError
and uncaught exceptions through build_error_response so every error body
is {detail, error_code, report?, trace?}. Fixes the bare-string body that
string HTTPException details produced, and registers the handler on the
Starlette base HTTPException so framework 404/405/415 also carry the full
envelope.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Introduces the flat ErrorMessage envelope builder with BAPI_SEND_REPORT /
BAPI_SEND_TRACE gating (report/trace off by default), plus the design
spec and implementation plan for the consistent-error-responses work.
Fixes#148Fixes#123
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Decoding a malformed or wrong-network invoice (e.g. a regtest lnbcrt...
invoice on a mainnet node) made each backend fail with a cryptic,
leaked error: LND with the Go 'strconv.ParseUint: parsing "rt500":
invalid syntax' surfaced as a 500, and CLN with 'Invalid bolt11: ...'.
Add a shared helper raise_for_pay_req_decode_error() in lightning/utils
that recognizes the decode-failure signatures of both backends and
raises one clear 400 pointing at the likely cause (malformed or wrong
network). Wire LND (lnd_grpc), CLN gRPC and CLN JSON-RPC through it so
they behave identically; genuine backend errors still return 500.
Fixes#225
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replaced by the /ws WebSocket channel. Deletes the SSE connection manager,
the vendored sse_starlette, and the unused /bitcoin/block-sub and
/system/hardware-info-sub streaming endpoints. Also removes the
test_block_sub_error.py regression test, which exclusively covered the
now-deleted handle_block_sub per-request generator (handle_block_sub_redis,
which broadcasts over /ws, is retained and unaffected).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replace the /sse/subscribe endpoint with a /ws WebSocket endpoint backed
by ws_mgr, and port the warmup helper (_send_sse_event -> _send_ws_event,
SSE -> Event, broadcast_sse_msg -> broadcast_msg). Also fixes two tests
left over from the prior SSE->Event/broadcast_msg rename that still
referenced the old names and were failing collection/execution.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
First commit of the SSE -> WebSocket migration (#252): the WebSocket
connection manager and its {type:auth,token} JWT handshake. Also lands
the migration's design spec and implementation plan.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
While LND is up but its RPC server is 'in the process of starting up, but
not yet ready to accept calls', every LND method returned a bare 500 -
the caller (e.g. the WebUI polling list-all-tx) got a generic server
error with no useful signal.
_check_if_locked only mapped the 'wallet locked' case; generalize it to
_check_transient_ln_error and also map the startup message to
425 TOO_EARLY (matching how bitcoind warmup is reported), with a clear
'try again shortly' detail. This covers all LND methods that share the
same error-handling path.
Fixes#247
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
On VM installs (e.g. Proxmox) the RaspiBlitz monitor scripts don't
populate keys like system_cpu_load / system_ram_mb / system_temp_celsius,
so redis returns empty strings. get_hardware_info did int('')/float('')
and raised ValueError, which killed the _handle_gather_hardware_info
background task ('Task exception was never retrieved') - hardware SSE
updates then stopped until restart.
- parse the hardware Redis values via _safe_int/_safe_float, returning
zero values instead of crashing (and guard the vram-percent division
by zero)
- wrap the gatherer loop body in try/except so a single failure can no
longer kill the task
Fixes#271
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Same #277 root cause in the block-subscription path: Bitcoin Core 28+
uses strict JSON-RPC 2.0, so an errored getblock/getbestblockhash reply
has no 'result' key. handle_block_sub and handle_block_sub_redis accessed
r['result'] unguarded, so a transient RPC error would raise
KeyError: 'result' and kill the block stream / block-update task.
Skip and log the block when the reply has no result instead of crashing.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bitcoin Core 28+ replies to a JSON-RPC 2.0 request with a strict 2.0
response: a success has a 'result' key but no 'error' key. The v1.11 code
did 'if result["error"] is not None' and crashed with KeyError: 'error'.
The getters are already guarded on dev with 'if "error" in result and
...'; add regression tests for get_network_info / get_blockchain_info so
that guard can't be dropped again (verified they fail against the old
unguarded form).
Fixes#277
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bitcoin Core returns the -28 warmup error ('Loading block index',
'Verifying blocks', 'Starting network threads') as an HTTP 200 response
with a JSON-RPC error body. _process_response only classified errors on
the non-200 path and passed a 200 body through unchanged, so the result
had an 'error' key but no 'status' key. Callers doing
'raise HTTPException(result["status"], ...)' then crashed with
KeyError: 'status' instead of HTTPException(425), so the startup
warmup-retry loop in initialize_bitcoin_repo never engaged and the API
(and login) failed while bitcoind was still warming up.
Same root cause, different -28 warmup message.
Fixes#287Fixes#285
Normalize any JSON-RPC error to an {error, status} dict regardless of the
HTTP status, mapping the warmup messages to 425 TOO_EARLY as before.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
_do_electrs_status_advanced only handled the negative cases: each guard
set installed/configured/status to its false-y value and returned early.
On the happy path (electrs installed, configured and running) it fell
through, populated the ports and sync details, but never set
s.installed/s.configured/s.status - so they kept their AppStatus
defaults (False/False/offline).
The /apps/status_advanced/electrs endpoint therefore reported electrs as
not installed and offline while simultaneously returning its ports and
sync details, disagreeing with the app_state_update_message status
(fusion44/blitz_api#286). Set the positive values when each guard passes.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
BaseChannelListener.listen() only called pubsub.unsubscribe() in its
finally block: the pubsub connection and the listener's own Redis client
were never released, leaking a connection for every install/uninstall
(_watcher) and every recreation of the app-status listener. The Celery
task notifiers were likewise never closed, and used the deprecated
Redis.close() instead of aclose().
- add aclose() to BaseChannelNotifier and BaseChannelListener
- listen() now closes the pubsub and its Redis client in finally
- close the notifiers in the app_manage / app_status_update tasks and
switch to aclose()
- back off in the app-status watch loop so a Redis outage no longer
spins, and drop a leftover debug print
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
get_event_loop() is deprecated on Python 3.11+ when there is no running
loop and is slated to change behaviour further.
- SSEManager.setup() ran at import time (app.api.utils) via
get_event_loop(); this only worked because uvicorn imports the app
inside its loop and would break when imported without a running loop
(e.g. a Celery worker). Start the broadcast consumer lazily from
within a running loop instead.
- everywhere else the pattern was get_event_loop().create_task(x)
inside a coroutine; replace with asyncio.create_task(x).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Replace the deprecated Pydantic v1 @validator('amount', pre=True,
always=True) with a v2 @model_validator(mode='after'). The model
validator always runs and can see both amount and send_all, preserving
the cross-field rule (and the always=True semantics that reject the
empty/default case). Removes the last Pydantic v1 deprecation warning.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@logger.catch defaults to reraise=False, so change_password and
get_debug_logs_raw - which raise NotImplementedError - silently
returned None. The service layer's 'except NotImplementedError -> 501'
never fired, yielding '200 null' or a response-model 500 instead.
login likewise turned unexpected errors into a None result.
Drop the pointless decorator from the two methods that only raise, and
let login reraise so failures surface.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The change-password endpoint accepted old_password/new_password as bare
str parameters, i.e. query parameters, so the passwords ended up in
access logs, proxy logs and browser history. Accept them in a
ChangePasswordInput request body instead.
Also mark the RaspiBlitz blitz.passwords.sh check/set invocations
sensitive=True so the plaintext passwords are not written to the debug
log, and guard against a missing password type (was an AttributeError
-> 500).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- uninstall_app dropped input.keep_data; _manage_app always ran the
bonus script with a bare 'off', so the RaspiBlitz script fell back to
an interactive whiptail prompt that hangs the non-interactive API.
Thread keep_data through and pass the explicit
--keep-data/--delete-data flag the scripts expect.
- install.{app_id}.log rendered as install.AppId.MEMPOOL.log because
str-enum formatting includes the class name on Python 3.11+; use
app_id.value here and in the CLN-incompatibility message.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two bugs in the CLN JSON-RPC list_all_tx:
- 'if pay is not Payment' compared each item to the Payment class rather
than its type, so it was always true and every payment was skipped -
payments never showed up in the transaction list.
- the successful_only filter appended the item inside the match branch
and then again unconditionally, so it never filtered anything.
Use isinstance for the type check and skip non-matching items when
successful_only is set. Also guard the source lists against None so a
failed sub-query no longer crashes the loop.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
sign_jwt added JWT_EXPIRY_TIME (seconds) to a milliseconds epoch and
stored it in a custom 'expires' claim, while register_cookie_updater
slept JWT_EXPIRY_TIME as seconds. With the code default (300) tokens
effectively expired almost immediately; with the sampled 3600000 the
cookie-refresh loop slept ~41 days, so the local .cookie held an
expired token nearly always. The custom claim also meant PyJWT never
validated expiry itself.
- issue standard 'iat'/'exp' claims (seconds) and let PyJWT validate,
requiring 'exp' on decode
- derive the cookie refresh interval from the same unit, guarded
against tiny/negative values
- default BAPI_JWT_EXPIRY_TIME to 3600s and fix .env_sample (was
3600000 'milliseconds')
Existing tokens and the local .cookie are invalidated by this change;
clients re-login and the cookie regenerates at startup.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
app_manage_task_impl released APP_MANAGE_LOCK_KEY and broadcast a
FINISHED message from its finally block unconditionally, including on
the early-return path where acquire_lock reported the lock as already
held by a running install. A duplicate install/uninstall request would
therefore delete the running task's lock (allowing concurrent
management of the same app) and send FINISHED, which stopped that
task's AppManageListener before it was done.
Track whether this task actually acquired the lock and only
release + finish when it did.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
'from redis.asyncio import ... TimeoutError' shadowed the builtin
TimeoutError. redis's TimeoutError is a RedisError subclass, not a
builtin subclass, so the 'except TimeoutError' guarding
asyncio.wait_for never matched: timed-out commands fell through to the
generic handler, the child process was never terminated (leak), and
the caller got a misleading 'unable to execute' error instead of a
timeout.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Two authenticated code paths interpolated user-controlled input into a
shell command:
- decode_pay_request passed the bolt11 string into _make_local_call,
which ran it via create_subprocess_shell; a crafted /lightning/
decode-pay-req request could execute arbitrary commands. Switch
_make_local_call to create_subprocess_exec with a discrete argv list.
- blitz_cln_unlock interpolated the wallet password into a
cl.hsmtool.sh invocation run through a shell, and logged it in the
clear. shlex.quote the interpolated values and mark the call
sensitive=True.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The WebUI only listens for the app_state_update_message SSE event to
populate the Apps tab. In bitcoin-only mode the warmup data was sent
under installed_app_status, which no client listens to, so the Apps
tab was stuck on the loading screen whenever the app status cache was
warm. Installing LND made it work again because the lightning warmup
path already used the correct event (raspiblitz#3608, raspiblitz#5141).
Also hardens the warmup path:
- reset the warmup_running flag on errors so a single failure no
longer starves all future SSE clients of warmup data
- convert per-source exceptions in the bitcoin-only warmup gather
instead of discarding the whole data set
- don't fall through to the partial-data branches when the API is
fully initialized with lightning disabled
- remove the now-unused INSTALLED_APP_STATUS event and the dead
cached_status_raw variable
Adds regression tests plus a conftest.py providing test env defaults
so the suite runs without a developer .env file.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* new endpoint: /lightning/unlock-wallet
* ln endpoints return HTTP_423_LOCKED status if wallet is locked
* bootup sequence defers ln listeners setup if wallet is locked
refs #34
This call currently fetches all invoices, payments and transactions each
time the endpoint is hit. TODO: Find a better way to cache this.
Possibly it is a good idea to build this list once on startup and
keep it updatedwhen new transactions roll in.
refs #30
