51a4b59ce82cadc25166c700719c37bc14b0b23b
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 archipelagoandClaude Opus 5
|
51a4b59ce8 |
fix(settings): card the Lightning section, and stop it crying "not installed" mid-rotation
Two operator reports on the same screen. The section had no card. Every other Settings section wraps itself in `glass-card px-6 py-6 mb-6` — AccountSection, AIDataAccessSection, NodeCertificateSection, BackupSection, the lot — and this one rendered as bare text on the page. Reported twice, because the wrapper lives in the new component and nothing about adding `<LightningCredentialsSection />` to SystemSection.vue's list tells you it is missing. Heading moved to h2/text-xl to match its siblings. A test now asserts the card, so a third report is not needed. And rotating told the operator Lightning did not exist. Rotation restarts LND, so `status.installed` reads false for a moment — and the template read that literally: "Lightning is not set up on this node yet, so there are no credentials to rotate. Install the Lightning app first." Seconds after rotating. On a node with a working wallet. It also replaced the progress they had every reason to be watching, on the one action that invalidates every credential their wallet holds. A container briefly absent is what rotating LOOKS like, not evidence Lightning was never there. The not-installed message is now gated on `!rotationInFlight`, which covers both `running: true` and the awaitUntil window between asking for a rotation and the node reporting one — `installed` can already be false in that gap, so gating on `running` alone would have left the same hole. Mid-rotation with no status yet says "Rotating credentials — Lightning is restarting" instead of falling through to a details block with empty fields. awaitUntil became a ref so the computed re-evaluates rather than holding a stale value until some other reactive dependency happens to change. Three tests: the card exists; a running rotation does not claim Lightning is missing; and — the half that matters just as much — a node with genuinely no Lightning still gets told there is nothing to rotate, so the fix has not simply hidden a true statement. 16/16, vue-tsc clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
1a98b2d0e7 |
fix(lnd-ui): don't cancel rotation polling before the node reports it running
Demo images / Build & push demo images (push) Successful in 3m24s
Writing the first tests for this section found the bug they were written to look for. `rotate()` started the poll, then the `load()` immediately behind it took a status snapshot that did not yet carry `running: true` and cancelled the interval — so the screen froze on the one action that most needs to show progress. The operator has just invalidated every credential their wallet holds, the rotation is genuinely running on the node, and the page tells them nothing is happening until they reload it by hand. It survived manual review because the backend flips `running` inside the same critical section that accepts the request, so the happy path usually wins the race. "Usually wins a race" is not a property to ship on a credential rotation. Polling now continues for a bounded window after a request the node accepted, and stops early as soon as `running` is observed. Bounded, so a request that was accepted but never acted on stops polling rather than hammering the node. 12 component tests cover the states that carry consequences: the channel census shown before the button is offered, the stale-BTCPay warning, the difference between "BTCPay has no internal node" (silence — an absence, not a fault) and "BTCPay's credential is dead" (a warning), the block on rotating while LND is unreachable, both poll races above, and that an idle tab does not wake the node. Verified: 12/12 new, 880/880 frontend tests, vue-tsc clean, and the rebuilt bundle contains the new strings. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
archipelagoandClaude Opus 5
|
d15cd58d7f |
feat(lnd): rotate Lightning macaroons from the dashboard, and stop stranding BTCPay
Demo images / Build & push demo images (push) Successful in 3m34s
Rotating LND's macaroons was an SSH-only script, which in practice meant it did not happen — while a macaroon is a bearer token with no revocation and no expiry, so anything that ever read one keeps the ability to spend until they are replaced. Settings → Lightning credentials now does it behind the node password, shows a step checklist, and refuses to report success unless it has confirmed the node identity and channel census are unchanged. Three findings from performing a real rotation on a dev node, each fixed here: 1. BTCPay was left holding a dead credential, silently. Its connection string carries the macaroon INLINE (LND's datadir is owned by its container subuid, so btcpay cannot bind-mount the file), and the daemon only regenerates that secret when LND's TLS cert thumbprint changes — which macaroon rotation does not touch. Result: btcpay up, LND up, both healthy, every Lightning payment failing, nothing anywhere saying why. 2. Rewriting the secret is not enough to fix it. `secret_env_hash` makes the change visible as env drift, but the reconcile loop runs `ExistingOnly` at boot AND periodically, and there it deliberately leaves running restart-sensitive apps untouched — observed once per tick for half an hour on the dev node. So this reuses FED-07's `credential_rotated` carve-out via a new default-no-op `ContainerOrchestrator::mark_credential_rotated`, on the same reasoning: restart sensitivity protects apps that are working, and this one is working only in appearance. The shell script cannot reach an in-process flag, so it removes the container and lets desired-state recovery rebuild it. 3. LND stayed locked forever on a loaded node. The unlocker is only served after channel.db/graph.db/wallet.db open, measured at 2m38s on a box running 30 containers; the unlock helper gave up at ~60s. That is not a harmless retry — reconcile records the post-start hook as failed, restarts LND, and the slow open begins again, so the wallet never opens and every LND-dependent app stays broken. The not-ready budget is now ~10 minutes; a genuinely wrong password still exits on the first pass via `all_rejected`. Safety properties worth not regressing: - No macaroon content in any response, error, log line or the polled progress feed — digests and byte counts only. - Rotation unlocks via a new `unlock_existing_wallet_no_wipe`, so there is no code path from "rotate my credentials" to `recreate_wallet_destructively`. A wallet whose password this node lacks fails the rotation with the wallet intact. - Channels are compared as active+inactive totals, not `num_active_channels`, which legitimately dips after any restart while peers reconnect. - Backup verified by file count before anything is deleted. Verified: cargo check + fmt clean, 6 new unit tests and the 6 existing container::lnd tests pass, vue-tsc clean, and the built bundle contains the three new RPC method names (the frontend build can silently no-op). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |