subservers: fail LiT startup when integrated sub-server boot fails

[ffranr]

Closes #1181

---

• Treat integrated sub-servers as fatal to startup and return an error if any fail to start.
• Propagate integrated sub-server startup errors to LiT so it stops launching and records the failure status.
• Update docs to reflect integrated sub-servers are now critical to startup.

[gemini-code-assist]

Summary of Changes

Hello @ffranr, 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 significantly enhances the reliability of the LiT startup sequence by elevating the status of integrated sub-servers to critical. Previously, LiT could continue operating even if some of its integrated sub-servers failed to launch. Now, any failure in an integrated sub-server's boot process will cause LiT itself to cease its startup, ensuring that the system only reaches an operational state when all essential integrated components are functioning correctly. This change provides a more robust and predictable initialization experience.

Highlights

• Critical Integrated Sub-Server Startup: Integrated sub-servers are now treated as critical components for LiT (Lightning Terminal) startup. If any integrated sub-server fails to initialize, LiT will now abort its launch process.
• Error Propagation: The StartIntegratedServers function in the sub-server manager has been updated to return an error if any integrated sub-server fails to start, allowing LiT to properly handle and propagate these failures.
• LiT Startup Robustness: LiT's main startup routine (terminal.go) now explicitly checks for errors returned by StartIntegratedServers and will set an errored status and halt its own startup if such failures occur.
• Documentation Update: Comments within the subservers/interface.go file have been updated to reflect the new critical nature of integrated sub-servers during LiT startup.

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 modifies the startup logic to treat integrated sub-server startup failures as fatal. The changes correctly propagate errors from StartIntegratedServers up to the main start function, causing LiT to fail on startup as intended. The documentation has also been updated to reflect this new behavior. The implementation is sound, but I have one suggestion to improve the consistency of error handling.

[ViktorT-11]

Thanks for this @ffranr 🙏!

In addition to the feedback I've commented below, this new behaviour definitely needs itest coverage.

I think we actually started working on this at the same time, and I have local branch with draft code implementing this + itest coverage. If you want to, i can clean that up and push it so that you can cherry-pick that to make it more simple for you. Let me know if that'd be helpful :).

[lightninglabs-deploy]

@ffranr, remember to re-request review from reviewers when ready

[ellemouton]

havent actually looked at the diff here yet, just want to make a note in case: we should just make sure that the daemon still runs & ie, that the status server still gets served