chore: migrate to start-sdk 2.0 - #24
Conversation
helix-nine
changed the title
|
Hey @helix-nine , @MattDHill, I have one concern about removing the Auto-Configure task completely. While LND 0.21 no longer needs the protocol.custom-message entries (and they actually cause the "feature bit 39 already set" error), BOLT12 Pay is still fully compatible with LND 0.20.x. I expect many node operators to stay on LND 0.20 for quite some time after the 0.21 release, especially larger routing nodes that tend to upgrade conservatively. Wouldn't it make more sense to keep the Auto-Configure task but make it version-aware? show/run the task only for LND < 0.21 The application itself doesn't depend on 0.21, it runs with both versions — only the configuration step changes. |
MattDHill
changed the title
|
@Alex71btc You're right, and thanks for catching it — I've dropped the LND 0.21 requirement. Pushed in 235828b. Your reasoning holds on both counts. BOLT12 Pay genuinely does run against LND 0.20 (only the configuration step differs, not the app), and StartOS 0.4.0 keeps running packages built against the pre-2.0 SDK — so an operator can absolutely be sitting on LND What changedImplemented as you suggested — the task is kept and made version-aware, rather than removed:
One wrinkle worth flagging, since it shapes the implementation: LND 0.21 doesn't just ignore the old keys — it removes the
Net effect:
Version is now Test plan
Flagging one thing I did not decide for you: your |
|
Thanks @helix-nine , excellent! |
|
Also release 0.3.0.1 has been merged already and a small follow-up fix PR 0.3.0:2 is pending for bolt 12 pay. |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01F5qZh4QiVySBLkV5ya7XSr
…n 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
- 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
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.
…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`.
…gure 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>
…rtos 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).
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 I just merged Internationalize Lightning Activity history into Alex71btc/lndk-pay main (69d0f9d), the upstream repo. |
… 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>
|
@Alex71btc Done — advanced
CI will rebuild against the new pin. Ready for another look whenever you are. |
|
Thanks — perfect! Yes, please add a short note to the 0.3.0:3 release notes so the user-facing History improvement is visible as well: “Also adds German and English translations for the Lightning Activity history UI.” Keeping the package version at 0.3.0:3 makes sense since the PR is still unreleased. |
…rtos 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).
|
Thanks for the review, @MattDHill — this merged and the Tag and Release workflow is cutting 0.3.0:3 now ( @Alex71btc, one honest flag: your 07-15 request to add the History note to the 0.3.0:3 release notes — "Also adds German and English translations for the Lightning Activity history UI" — slipped through before the tag was cut, so it's not in the shipped :3 notes. My miss. The feature itself did ship in :3, though: the Since :3 is now released I can't edit its notes retroactively. Your call on how to surface it:
Happy to open the |
3 participants
start-sdk 2.0 migration
Migrates this package to
@start9labs/start-sdk2.0 (requires StartOS 0.4.0-beta.10).Changes
2.0.1, TypeScript →^6,tsconfig.jsonextends the shippedtsconfig.base.json,Makefileincludes the SDK'ss9pk.mk(vendored copy removed), reusable CI workflows repointed toStart9Labs/start-technologies.sdk.serviceInterface.*→sdk.host.*resolved over the LXC bridge, lazySubContainer,alertsmanifest field removed, and other### Changed/### Removeditems from the SDK 2.0 changelog.Upstream submodule sync
upstream/submodule (Alex71btc/lndk-pay) to latestmain(bec0899). The SDK-2.0 migration commit had inadvertently reverted the gitlink toe9707a1("Release v0.2.111"); this restores it and brings the branch level with — and one commit past —main'sea7432fpin.e9707a1: LND 0.21 RouterRPC payment fixes, CSRF fix for LNURL payments, native onion-messaging detection for LND 0.21+, server-side SQLite offer history + BIP353 management, copy support for payment results, and LNURL translation fixes.npm updaterefreshed the transitive#nextgit-ref deps (lnd-startos,bitcoin-core-startos).0.2.116:2— the substantive upstream content (throughea7432f) is already whatmainlabels 0.2.116; the only newer commit (bec0899) is a root-README edit that never reaches the image.packageRepois already canonical (Start9-Community/bolt12-pay-startos).Test plan
npm ci→tsc→ SDK lint →ncc→s9pk pack).0.2.116:2.s9pkon a StartOS 0.4.0-beta.10 server that already has LND 0.21.0-beta+ installed and unlocked./mnt/lndmount).🤖 Generated with Claude Code