Bolt12 Pay v 0.3.0:2 Restore NWC initialization after admin page startup refactor - #27
Merged
MattDHill merged 1 commit intoJul 13, 2026
Conversation
Alex71btc
changed the title
Author
|
This issue was discovered during the final verification after the Transaction History release had already shipped. It prevented NWC initialization after the admin page startup refactor, log in button was dead. Now fixed and re-tested successfully on LND v0.20.x and v0.21.x. |
MattDHill
approved these changes
Jul 13, 2026
helix-nine
added a commit
that referenced
this pull request
Jul 13, 2026
Rebases `next` onto `main` after PR #27 merged, and drops the work that became redundant. PR #27 independently did the same upstream submodule bump this branch was carrying (both landed on 54a4b5f, "Restore NWC initialization after admin page startup refactor") and released it as 0.3.0:2. So that commit is now a no-op here, and its release notes would have re-announced, under 0.3.0:3, the NWC fix that 0.3.0:2 already shipped. Dropped it; the submodule is unchanged relative to main. The release notes now describe what this version actually adds over 0.3.0:2: - LND 0.20 support alongside 0.21, with a version-aware Auto-Configure task. Onion messages are configured differently on the two — 0.21 advertises them natively and crash-loops if the pre-0.21 protocol.custom-* overrides are set, while 0.20 requires them — so the task is posted only to pre-0.21 nodes and clears itself when LND is upgraded, rather than stranding the user with a critical task a 0.21 node can no longer satisfy. - Reactive dependency address resolution, so main no longer restarts on every dependency update and heals with one restart when a dependency is installed later, removed, or changes port. - Internal start-sdk 2.0.x updates. Also keeps this branch's CI fix rather than letting the rebase regress it: main's workflows point at `start9labs/shared-workflows`, which is retired — the callers here reference `Start9Labs/start-technologies`. Verified: lockfile resolves start-sdk 2.0.5 with no nested stale copy and is at a fixed point; `npm run check` (tsc --noEmit) green.
helix-nine
added a commit
that referenced
this pull request
Jul 13, 2026
Rebases `next` onto `main` after PR #27 merged, and drops the work that became redundant. PR #27 independently did the same upstream submodule bump this branch was carrying (both landed on 54a4b5f, "Restore NWC initialization after admin page startup refactor") and released it as 0.3.0:2. So that commit is now a no-op here, and its release notes would have re-announced, under 0.3.0:3, the NWC fix that 0.3.0:2 already shipped. Dropped it; the submodule is unchanged relative to main. The release notes now describe what this version actually adds over 0.3.0:2: - The Auto-Configure task is version-aware. LND's dependency floor is unchanged (>=0.20.1-beta:12 on both branches — 0.20 support was never lost), but master posts the task unconditionally, including to 0.21 nodes. That is wrong in two ways: 0.21 advertises onion messages natively and its config spec drops the toggle entirely, so the task is a *critical* item the user cannot satisfy; and setting the pre-0.21 protocol.custom-* overrides on 0.21 aborts server creation ("feature bit: 39 already set") and crash-loops LND. The task is now posted only to pre-0.21 nodes and cleared when LND is upgraded. - Reactive dependency address resolution, so main no longer restarts on every dependency update and heals with one restart when a dependency is installed later, removed, or changes port. - Internal start-sdk 2.0.x updates. Also keeps this branch's CI fix rather than letting the rebase regress it: master's workflows point at `start9labs/shared-workflows`, which is retired — the callers here reference `Start9Labs/start-technologies`. Verified: lockfile resolves start-sdk 2.0.5 with no nested stale copy and is at a fixed point; `npm run check` (tsc --noEmit) green.
helix-nine
added a commit
that referenced
this pull request
Jul 23, 2026
* chore: migrate to start-sdk 2.0 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F5qZh4QiVySBLkV5ya7XSr * feat: resolve dependencies over the bridge reactively; restart only on real address changes Doctrine v3 (issue start-technologies#3407): dependency addresses go through a utils.ts bridgeAddress helper chained .const() — the mapped value is the minimal bridge address, so main never restarts on dependency updates, and heals with one restart when a dependency is installed after this service, uninstalled, or changes port. Cross- package container IPs and .startos dials are gone; static config defaults become loopback placeholders; tor consumers fold the allocator-guaranteed 9050 fallback into the map. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PpJxhk25X42WTafMdkUx6t * fix: apply PR review feedback - no fabricated dependency addresses: absent dependency => absent config/env value (optional fields, omitted keys), never a fake 127.0.0.1 dial default - dependency-task accept entries match absent-when-default fields (prune: 0 or absent both accepted) - neutral naming: the Bitcoin dependency is 'Bitcoin', not 'Bitcoin Core'/'Bitcoin Knots', across prose, release notes, and i18n - instructions.md keeps no version/migration notes - remove orphaned i18n entries added by the migration - normalize the bridgeAddress helper to an explicit early-return and prettier-format wave-touched files Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PpJxhk25X42WTafMdkUx6t * chore: bump start-sdk to 2.0.3 Bumps @start9labs/start-sdk ^2.0.1 -> 2.0.3 (dependency and lockfile only). - 2.0.3 fixes a dependency-gated daemon wedging permanently after its dependency's readiness flaps: Daemon.term() unconditionally destroyed the daemon's SubContainer, so the next start() threw "already destroyed" and the daemon never recovered. Adds a non-destroying Daemon.stop() for dependency-driven pauses, and serializes pause/resume transitions. - 2.0.2 runs s9pk.mk's check-deps before packing, not just before install. No packaging API changed between 2.0.1 and 2.0.3, so no source changes were needed. Verified with `npm run check` (tsc --noEmit). Also pins the dependency exactly rather than with a caret range, matching the convention used by every other package in both registries. * chore: refresh bitcoin-core-startos, lnd-startos pin to current next head Re-resolves the git-ref dependencies (bitcoin-core-startos, lnd-startos) to the current head of the branch each spec points at. These pins predated the start-sdk 2.0.3 bump, so each dependency dragged a nested @start9labs/start-sdk 2.0.1 into this package's lockfile. They now resolve to 2.0.3 and dedupe against the top-level copy, leaving no 2.0.1 anywhere in the tree. Lockfile only; package.json is unchanged. Verified with `npm run check`. * feat: support LND 0.20 alongside 0.21 with a version-aware Auto-Configure task BOLT12 Pay runs fine against LND 0.20 — only the onion-message configuration step differs — so requiring >=0.21 would lock out operators who upgrade LND conservatively, for no functional gain. Restore the dependency floor to >=0.20.1-beta:12 and post LND's hidden autoconfig task only where it is actually needed: LND advertises onion messages natively from 0.21 (feature bit 39) and aborts server creation if the pre-0.21 protocol.custom-* overrides are also set, while 0.20 requires them. The installed version is read with sdk.getServiceManifest(...).const(), so upgrading LND from 0.20 to 0.21 re-runs init and clears the task instead of stranding the user with a critical task that a 0.21 node can no longer satisfy. LND 0.21's config spec drops the onion-messages toggle entirely, so the typed action we import can no longer describe the field; the task is posted through the raw effects.action.createTask with the same replayId the SDK helper derives. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore: bump start-sdk to 2.0.5; refresh bitcoin-core-startos, lnd-startos pins Bumps @start9labs/start-sdk 2.0.3 -> 2.0.5 (dependency and lockfile only). 2.0.5 fixes ExVer range operations ignoring the downstream revision: compareVersionRangePoints and adjacentVersionRangePoints compared the upstream twice, so two points sharing an upstream but differing downstream (1.0.0:3 vs 1.0.0:15) collapsed into one. normalize() then dropped the lower of the two, which made packed manifests advertise a canMigrateFrom/canMigrateTo range narrower than the truth for any package whose `other` versions share current's upstream. No upgrade path actually broke — StartOS resolves migrations through the version graph rather than this field — but the manifests were wrong. Also re-resolves the git-ref dependencies (bitcoin-core-startos, lnd-startos) to the current head of the branch each spec points at, so they carry start-sdk 2.0.5 too and dedupe against the top-level copy instead of nesting a stale one. No packaging API changed, so no source changes were needed. Verified with `npm run check` (tsc --noEmit). * chore: rebase onto main; 0.3.0:2 → 0.3.0:3 Rebases `next` onto `main` after PR #27 merged, and drops the work that became redundant. PR #27 independently did the same upstream submodule bump this branch was carrying (both landed on 54a4b5f, "Restore NWC initialization after admin page startup refactor") and released it as 0.3.0:2. So that commit is now a no-op here, and its release notes would have re-announced, under 0.3.0:3, the NWC fix that 0.3.0:2 already shipped. Dropped it; the submodule is unchanged relative to main. The release notes now describe what this version actually adds over 0.3.0:2: - The Auto-Configure task is version-aware. LND's dependency floor is unchanged (>=0.20.1-beta:12 on both branches — 0.20 support was never lost), but master posts the task unconditionally, including to 0.21 nodes. That is wrong in two ways: 0.21 advertises onion messages natively and its config spec drops the toggle entirely, so the task is a *critical* item the user cannot satisfy; and setting the pre-0.21 protocol.custom-* overrides on 0.21 aborts server creation ("feature bit: 39 already set") and crash-loops LND. The task is now posted only to pre-0.21 nodes and cleared when LND is upgraded. - Reactive dependency address resolution, so main no longer restarts on every dependency update and heals with one restart when a dependency is installed later, removed, or changes port. - Internal start-sdk 2.0.x updates. Also keeps this branch's CI fix rather than letting the rebase regress it: master's workflows point at `start9labs/shared-workflows`, which is retired — the callers here reference `Start9Labs/start-technologies`. Verified: lockfile resolves start-sdk 2.0.5 with no nested stale copy and is at a fixed point; `npm run check` (tsc --noEmit) green. * chore: advance upstream submodule to 69d0f9d (i18n Lightning Activity history) Points ./upstream (Alex71btc/lndk-pay) at latest main, bringing in the internationalized Lightning Activity history UI (ac72629, d40ad07, merged in 69d0f9d). Clean fast-forward from 54a4b5f; only the frontend translations change, which the Dockerfile bakes into the image via `COPY upstream/app/`. Package version stays 0.3.0:3 (this PR is unreleased). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore: bump start-sdk to 2.0.6; refresh bitcoin-core-startos, lnd-startos pins Bumps @start9labs/start-sdk 2.0.5 -> 2.0.6 (dependency and lockfile only). 2.0.6 fixes s9pk.mk failing under `make` in a git repo with no index yet: it listed $(GIT_DIR)/index as an unconditional prerequisite, but `git init` creates no index until the first `git add`, so a freshly scaffolded package aborted with "No rule to make target '.git/index'" before packing. GIT_DEPS now filters through $(wildcard ...), so a missing HEAD or index drops out of the prerequisite list instead of halting the build (s9pk pack already handles a commit-less repo). Build plumbing only. Also re-resolves the git-ref dependencies (bitcoin-core-startos, lnd-startos) to the current head of the branch each spec points at, so they carry start-sdk 2.0.6 too and dedupe against the top-level copy instead of nesting a stale one. No packaging API changed, so no source changes were needed. Verified with `npm run check` (tsc --noEmit). --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This follow-up release fixes another regression discovered during final end-to-end testing after the Transaction History release.
Fix
Testing
Re-tested successfully on StartOS with:
Tested on both LND v0.20.x and LND v0.21.x.