Since lnd may call into tapd when it is enabled, tapd must be started successfully before those calls are made.
Previously, we've allowed litd to start successfully even if one or more sub-servers (except lnd) failed during startup. The reasoning behind this decision was that bugs in individual sub-servers should not prevent users from running the rest of their litd node until those bugs are patched.
However, because tapd is tightly coupled to lnd when it is in use, we need to modify this behavior specifically for the tapd sub-server. If tapd is enabled and errors during the startup, litd should also fail to start.
Since
lndmay call intotapdwhen it is enabled,tapdmust be started successfully before those calls are made.Previously, we've allowed
litdto start successfully even if one or more sub-servers (exceptlnd) failed during startup. The reasoning behind this decision was that bugs in individual sub-servers should not prevent users from running the rest of theirlitdnode until those bugs are patched.However, because
tapdis tightly coupled tolndwhen it is in use, we need to modify this behavior specifically for thetapdsub-server. Iftapdis enabled and errors during the startup,litdshould also fail to start.