zeus-node-lifecycle-campaign

Diagnose and fix embedded LND and LDK node lifecycle races in the Zeus mobile wallet.

Updated Sep 2, 2026
One-click install
npx skills add https://github.com/aswin-dev-debug/Ai-Finance-analyzer --skill zeus-node-lifecycle-campaign-aswin-dev-debug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: zeus-node-lifecycle-campaign
Source: https://github.com/aswin-dev-debug/Ai-Finance-analyzer/tree/main/lib/zeus-contrib/zeus/.claude/skills/zeus-node-lifecycle-campaign
Command: npx skills add https://github.com/aswin-dev-debug/Ai-Finance-analyzer --skill zeus-node-lifecycle-campaign-aswin-dev-debug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Zeus's embedded Lightning nodes (LND and LDK Node) crash, hang, or duplicate during start, stop, delete, and wallet-switch operations due to race conditions spread across Wallet.tsx, SettingsStore flags, JS utilities, and native modules. This Skill provides a verified lifecycle state map, reproducible baseline experiments, and a ranked fix menu so engineers can measure, diagnose, and repair these races without guesswork. ## Core Features & Use Cases - Verified lifecycle state machine: Documents the four-layer ownership of node lifecycle (Wallet.tsx orchestration, SettingsStore flags like fetchLock/connecting, JS node control utilities, and native Kotlin/Swift modules) with commit-hash citations. - Baseline experiment suite (Phase 0-5): Provides reproducible experiments with exact adb logcat and iOS log commands, grep-able log milestones, and decision gates for cold starts, rapid wallet switches, wallet deletion, background storms, and JS reloads. - Ranked solution menu with fenced wrong paths: Offers three ordered fixes (fetchData lock hygiene, cross-implementation teardown, LDK stop/delete hardening) with theory obligations, blast radius, and PR gates. - Use Case: A maintainer sees users reporting SIGABRT crashes when switching from an embedded LND wallet to an LDK Node wallet. Load this Skill to run experiment E2, confirm via the old-node liveness probe that the previous node keeps running (window W3), then implement the cross-implementation teardown fix with its required evidence. ## Quick Start Load this skill and ask the AI to reproduce the wallet-switch crash between embedded LND and LDK Node using the Phase 0 baseline experiments and logcat milestones.

Frequently Asked Questions about zeus-node-lifecycle-campaign

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug Zeus wallet crashes when switching between LND and LDK nodes?

Run the E2 rapid wallet-switch experiment: capture adb logcat filtered for LdkNodeModule, LndMobileService, and FATAL tags, then tail the old wallet's lnd.log or ldk_node.log. Per the verified code read, the previous node keeps running after a cross-implementation switch (window W3), which the liveness probe confirms.

Why does Zeus show Node not initialized errors on LDK Node?

The error appears when JS calls the LDK FFI while buildNode is rebuilding the native node, because buildNode clears the JS-visible reference up front. waitForLdkNodeReady tolerates it with retries, but other store call sites during the rebuild window are unguarded and surface the error.

What causes Tokio SIGABRT crashes when stopping an LDK node on mobile?

The crash happens when the last reference to the Node object is dropped from a Tokio worker thread, destroying the Rust runtime from inside itself. The native modules prevent this by stopping on a dedicated non-Tokio thread and holding the reference two extra seconds after stop resolves.

Does this skill cover general Zeus debugging or only node lifecycle issues?

It covers only node start/stop/delete/switch races and Wallet.tsx connection flow. For general symptom triage, log capture tooling, backend capability questions, or PR rules, it explicitly defers to sibling skills like zeus-debugging-playbook and zeus-change-control.

Why does Zeus hang on the connecting spinner after an error?

fetchData sets fetchLock on entry but only clears it on the happy path or via setConnectingStatus(true); every early-return error path leaves the lock stranded by design. If no UI affordance calls setConnectingStatus(true) afterward, focus events silently no-op and the spinner persists.

Can I fix LDK delete timing issues by adding a longer JavaScript sleep?

No. The skill explicitly fences time-based sleeps as symptom patches; the delete flow's existing 2-second sleep is cited as an anti-pattern. Fixes must use a real completion signal, such as native-side deletion after the Arc-hold, changed symmetrically in the Kotlin and Swift modules.