fix: register SubscribeState listener before starting stream

[ajaysehwal]

Description

Please enter a description and screenshots, if appropriate, of the work covered in this PR

Problem

When starting the embedded LND node, the app logs:

Sending SubscribeState with no listeners registered

This happens because the native side starts emitting SubscribeState events as soon as subscribeState() is called, but the JS listener was only registered when waitForState() was invoked at the end of waitForLndReady, after subscribeState() had already run.

Solution

Register the SubscribeState listener before calling subscribeState() by invoking waitForState() at the start of waitForLndReady. That way the listener is in place before the native stream begins emitting events.

Changes

In utils/LndMobileUtils.ts, call waitForState() before subscribeState() and return the resulting promise instead of calling waitForState() only at the end

This pull request is categorized as a:

• New feature
• Bug fix
• Code refactor
• Configuration change
• Locales update
• Quality assurance
• Other

Checklist

• I’ve run yarn run tsc and made sure my code compiles correctly
• I’ve run yarn run lint and made sure my code didn’t contain any problematic patterns
• I’ve run yarn run prettier and made sure my code is formatted correctly
• I’ve run yarn run test and made sure all of the tests pass

Testing

If you modified or added a utility file, did you add new unit tests?

• No, I’m a fool
• Yes
• N/A

I have tested this PR on the following platforms (please specify OS version and phone model/VM):

• Android
• iOS

I have tested this PR with the following types of nodes (please specify node version and API version where appropriate):

• Embedded LND
• LND (REST)
• LND (Lightning Node Connect)
• Core Lightning (CLNRest)
• Nostr Wallet Connect
• LndHub

Locales

• I’ve added new locale text that requires translations
• I’m aware that new translations should be made on the ZEUS Transfix page and not directly to this repo

Third Party Dependencies and Packages

• Contributors will need to run yarn after this PR is merged in
• 3rd party dependencies have been modified:
  • verify that package.json and yarn.lock have been properly updated
  • verify that dependencies are installed for both iOS and Android platforms

Other:

• Changes were made that require an update to the README
• Changes were made that require an update to onboarding

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a timing issue during the initialization of the embedded LND node. By adjusting the order of operations, it guarantees that the necessary event listener is active before the system starts emitting state updates, thereby eliminating a recurring warning message and ensuring robust event handling from the outset.

Highlights

• Bug Fix: SubscribeState Listener Timing: Addressed a bug where the SubscribeState listener was registered after subscribeState() was called, leading to 'Sending SubscribeState with no listeners registered' log messages during LND node startup.
• Improved Event Handling: Ensured the SubscribeState listener is in place before the native stream begins emitting events by invoking waitForState() at the beginning of waitForLndReady.

Changelog

• utils/LndMobileUtils.ts
  • Reordered the invocation of waitForState() to occur before subscribeState() within the waitForLndReady function.

Activity

• No human activity has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses a race condition where the SubscribeState listener was registered after the subscription started, which could lead to missed events. The change reorders the operations to register the listener first. My review includes one high-severity comment regarding a potential unhandled promise rejection introduced by this change, with a suggestion for how to refactor the code to handle all error cases robustly.

[gemini-code-assist]

This change correctly fixes the race condition for the SubscribeState listener. However, it introduces a potential for an unhandled promise rejection.

If await subscribeState() throws an error, the waitForLndReady function will reject and exit. The statePromise created by waitForState() will be orphaned. Since it's no longer referenced, its eventual rejection (e.g., on timeout) will be unhandled, which can crash the application in some environments.

To address this, I recommend refactoring waitForLndReady to ensure that any failure during the subscription process also rejects the main promise. This can be achieved by moving the subscription logic inside the promise that waits for the state.

Here's a conceptual example of the refactoring:

async function waitForLndReady(...) {
    return new Promise(async (resolve, reject) => {
        // ... (logic from waitForState, including stateHandler, cleanup, settle, timeout)
        
        LndMobileEventEmitter.addListener('SubscribeState', stateHandler);

        try {
            await sleep(LISTENER_REGISTRATION_MS);
            await subscribeState();
        } catch (error) {
            // This will now correctly reject the main promise
            settle(() => reject(error));
        }
    });
}

This ensures that the entire asynchronous operation is atomic and properly handles all error cases.

[kaloudis]

ACK

not sure this fixes all the cases, but I don't think this will hurt. merging in