You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As currently architected, at litd start up, in order to open the UX, all of the subservers need to startup meaning all of the litd dependencies (LND version, etc.) have to be aligned. With that behavior, for users using GUI experiences because of ease or lack of technical skills, when a litd update occurs that changes dependencies, they encounter an issue where the app or experience doesn't open due to dependency mismatch. However, given this user type, it can be difficult for them to debug the issue and understand the problem and solution.
Potential Solution
We could re-architect litd so that it can actually "startup" without all of the subservers being activated. With this architecture, we could show the user the relevant errors or dependency issues so that they can more easily debug. The example referenced in the attached issue would mean that we show the user in the UX that they need to be running lnd 0.15.1 for litd to work properly. But, we've also run into issues in the past whereby the entire litd experience doesn't start because of a single subserver issue (Pool most of the time). With this architecture, we might be able to have everything else work, but in the Pool UX flag the error to the user to help them and us debug it. This would probably require an always-on RPC for the UI to obtain the current status or startup errors.
An additional feature that could be a part of this is being able to configure the subservers from the UI. Then, there would be less flags that need to be specified via the CLI.
Uh oh!
There was an error while loading. Please reload this page.
Problem
As currently architected, at
litd
start up, in order to open the UX, all of the subservers need to startup meaning all of thelitd
dependencies (LND version, etc.) have to be aligned. With that behavior, for users using GUI experiences because of ease or lack of technical skills, when alitd
update occurs that changes dependencies, they encounter an issue where the app or experience doesn't open due to dependency mismatch. However, given this user type, it can be difficult for them to debug the issue and understand the problem and solution.Potential Solution
We could re-architect litd so that it can actually "startup" without all of the subservers being activated. With this architecture, we could show the user the relevant errors or dependency issues so that they can more easily debug. The example referenced in the attached issue would mean that we show the user in the UX that they need to be running
lnd 0.15.1
for litd to work properly. But, we've also run into issues in the past whereby the entirelitd
experience doesn't start because of a single subserver issue (Pool most of the time). With this architecture, we might be able to have everything else work, but in the Pool UX flag the error to the user to help them and us debug it. This would probably require an always-on RPC for the UI to obtain the current status or startup errors.An additional feature that could be a part of this is being able to configure the subservers from the UI. Then, there would be less flags that need to be specified via the CLI.
Referenced Issue: #420
The text was updated successfully, but these errors were encountered: