fix: sigabrt runtime teardown

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.

[ovitrif]

Fixes#110

Summary

• Make Node the sole owner of the Tokio runtime and give tasks and exported child handles non-owning runtime control.
• Close task admission, gate Electrum callbacks, and drain or cancel tracked work before runtime disposal.
• Isolate VSS I/O on a store runtime whose fallback disposal is safe from async contexts.
• Propagate event-processor persistence failures after cleanup and remove shutdown panic paths.
• Bump all package surfaces to 0.7.0-rc.66 and regenerate Android, JVM, Python, and Swift artifacts without changing the public or UniFFI APIs.

Validation

• Local verification: cargo fmt --all -- --check, RUSTFLAGS='-D warnings' cargo build, cargo check --release --features uniffi, and cargo test --features uniffi --lib (107 passed); focused runtime, Electrum, VSS, and release-mode regressions passed.
• ./bindgen.sh regenerated JVM, Python, Swift, and Android artifacts for 0.7.0-rc.66; package builds, Maven Local publication, Swift checksum, native debug-symbol matching, and 16 KiB alignment checks passed.
• Android Maven Local validation: the signed bitkit-dev-release-188-universal.apk from devRelease completed 100 consecutive in-app LDK node restarts on an arm64-v8a Android 16/API 36 emulator without SIGABRT or Tokio runtime-shutdown failures.

Release

• v0.7.0-rc.66

[ovitrif]

Validate ldk-node PR #111 in Bitkit Android

Objective

Validate the exact native library from synonymdev/ldk-node PR #111 inside a Bitkit Android build before publishing another ldk-node package.

The validation must exercise Bitkit's real node stop, destroy, and rebuild paths. It does not need the ldk-node channel_full_cycle integration test or any splicing flow.

Recorded Android validation

• ldk-node head: dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Maven Local coordinate: com.synonym:ldk-node-android:0.7.0-rc.65-pr111.dc37559.
• App build: signed bitkit-dev-release-188-universal.apk from the devRelease build type.
• Device: arm64-v8a Android 16/API 36 emulator.
• Lifecycle result: 100 consecutive in-app LDK Debug node restarts completed without SIGABRT or Tokio runtime-shutdown failures.
• Native provenance: the APK's arm64-v8a libldk_node.so Build ID was 20b0b1bc8e28be7e153b5265e3c3f094c37ae6fa, matching the Maven Local AAR.

Inputs and isolation

• Use the latest reviewed PR fix: sigabrt runtime teardown #111 head and record its full commit SHA before building. The current head is dc37559a9eb6c68bf2ce1ed81b49eb58e25e0fe3.
• Derive a unique Maven Local version from that head, for example 0.7.0-rc.65-pr111.dc37559, so the artifact cannot be confused with a released rc.65 package.
• Use a temporary Bitkit Android validation worktree based on the intended app baseline. Keep the existing checkout and unrelated work unchanged.
• Save commands, dependency evidence, Build IDs, device details, and logs under .ai/logs/<YYYY-MM-DD>/ldk-pr111-android/.

Build and publish the local ldk-node artifact

1. Confirm the ldk-node worktree is clean and its checked-out SHA is the recorded PR head.
2. Run scripts/uniffi_bindgen_generate_kotlin_android.sh with ORG_GRADLE_PROJECT_version set to the unique local version.
   • The existing script builds release-smaller native libraries for armeabi-v7a, arm64-v8a, and x86_64.
   • It generates the Kotlin bindings and native debug-symbol archive.
   • It validates stripped libraries and 16 KB alignment.
   • It publishes com.synonym:ldk-node-android:<localVersion> to Maven Local.
3. Verify Maven Local contains the AAR, POM, sources, Javadoc, and native-debug-symbols artifact for the unique coordinate.
4. Record the Build ID and SHA-256 of each ABI's libldk_node.so from the AAR and debug-symbol archive.

Consume the artifact from Bitkit Android

1. Change only gradle/libs.versions.toml in the validation worktree from 0.7.0-rc.63 to the unique local version.
2. Keep mavenLocal() first in settings.gradle.kts; it is already configured correctly.
3. Run dependency insight for devDebugRuntimeClasspath with refreshed dependencies and require it to resolve the unique com.synonym:ldk-node-android version.
4. Run the focused host-side lifecycle tests:
   • LightningServiceTest
   • LightningNodeServiceTest
5. Build assembleDevDebug only as a fast diagnostic artifact, then build assembleDevRelease as the device-validation artifact.
   • Install and exercise devRelease, not devDebug, so Kotlin/JNI packaging and runtime behavior match the release build type.
   • If the production release keystore is unavailable locally, sign the generated devRelease APK with the repository's debug keystore after assembly. Do not change the build type or source configuration.
6. Extract the packaged lib/arm64-v8a/libldk_node.so from the devRelease APK and require its Build ID and SHA-256 to match the Maven Local AAR. This is the provenance gate proving the tested app contains PR fix: sigabrt runtime teardown #111.

Exercise the real Android lifecycle

1. Prefer an arm64 Android 16 physical device matching the production reports. Use an arm64 emulator when no physical device is available and record that limitation.
2. Install the locally signed devRelease APK, initialize a regtest wallet, and wait until the LDK node is running and synchronized against the local test backend.
3. Open LDK Debug and automate the existing Restart action. Each iteration must wait for Node restarted successfully before starting the next one.
4. Run 10 consecutive stop/destroy/start cycles with stable Electrum connectivity, including the first manual cycle and nine repetitions. Do not open channels or invoke splice APIs.
5. Capture filtered adb logcat and the app's private logs for the full run.
6. Fail immediately and preserve evidence if any cycle produces:
   • Cannot drop a runtime in a context where blocking is not allowed.
   • A Tokio 1.x context was found, but it is being shutdown.
   • SIGABRT, a native tombstone, or an unexpected app-process restart.
   • Node handle release still pending, NodeReleaseTimeout, or a restart that exceeds the existing release bound.
   • A second node starting before the previous native handle is released.

Repository checks

• Run just compile, just test, and just lint with the local dependency selected.
• Keep the ldk-node focused Rust/UniFFI/runtime tests from PR fix: sigabrt runtime teardown #111 as the native-layer gate.
• Do not use the unrelated splicing integration suite as evidence for this fix.

Acceptance and evidence

• Dependency insight resolves the unique Maven Local coordinate.
• The AAR, debug symbols, and tested devRelease APK contain matching libldk_node.so Build IDs.
• All focused lifecycle tests and repository checks pass.
• Every device cycle completes within the existing release bounds.
• Both production Tokio panic signatures remain absent.
• No native abort, tombstone, stale-node poll, overlapping node lifetime, or release timeout occurs.
• The evidence bundle contains the PR SHA, local coordinate, device/API/ABI, Build IDs, commands, test results, logcat, and app logs.

Cleanup and reporting

• Restore gradle/libs.versions.toml after validation and require the Bitkit validation worktree to be clean.
• Keep the uniquely versioned Maven Local artifact until review completes; it can be removed later without affecting released coordinates.
• Keep this PR's Validation section synchronized with the recorded Android result, including the exact app build, device, cycle count, and Build ID.
• Do not publish a new ldk-node version or permanently update Bitkit Android until this local gate passes.

[coreyphillips]

Thanks for tackling this. I think three lifecycle gaps still need to be addressed before merging:

• Exported payment and liquidity handles can pass the running check, race Node teardown, and call RuntimeControl::block_on after the owned runtime has shut down. I reproduced the Tokio context is being shutdown panic.
• The timeout branches at src/runtime.rs:272 and src/runtime.rs:310 detach live background or event processing work while allowing stop() to succeed. A restart can then overlap the old generation against the same state and store.
• ConfirmGate holds its mutex across external Confirm callbacks. begin_shutdown() can block forever behind persistence, and a callback panic poisons the gate and causes shutdown to panic.

Could we close these gaps and add focused regression coverage before merging?

[ovitrif]

Addressed the three lifecycle gaps in b5c0b55:

1. Exported payment/liquidity block_on now takes a runtime-use read lock. After Runtime drop, try_block_on returns NotRunning instead of panicking on a shutting-down Tokio handle. Drop waits for in-flight handle calls before shutdown_background().
2. Timed-out background and event-processor work is retained. start() drains that leftover generation before admitting new tasks, and returns AlreadyRunning if it is still live.
3. ConfirmGate is an AtomicBool. begin_shutdown() no longer waits on confirm callbacks or panics if a callback poisons a mutex.

Focused runtime and Electrum regressions cover the three cases.