-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
When running LND with Taproot Assets Aux units, currently we call into the tapd software and we do not timeout the calls to the daemon, instead there is a possibility that some goroutines on the LND site hang up, and it is only now visible via other side effects we do not see immediately what the problem is, so we need to always analyse a goroutine dump to acutally understand what the problem is.
An example:
Tapd starts => LND Starts => LND calls into Tapd
We might call into tapd if during startup a channel is recognized of being closed, this function is called to dispatch the ForceClose Summary:
Lines 7039 to 7044 in 85a5bf2
| resolveBlob := fn.MapOptionZ( | |
| auxResolver, | |
| func(a AuxContractResolver) fn.Result[tlv.Blob] { | |
| return a.ResolveContract(resolveReq) | |
| }, | |
| ) |
Now if for some reason the tapd is not ready (see attached log, which was a problem on the tapd side) LND will not signal something but just hang up the call, and the goroutine basically starvs without the LITD runner knowing why.
talked with @ffranr and we should implement the fix on both sides:
- We implement the Future<=>Promise design from 9bd73c6
- Ask for a specific behaviour of the Aux Unit which then resturns a future
- This future as a context we can cancel if we timeout and it just takes too long
That way we don't have to do some retry logic, we ask for the AuxUnit to do a specific thing, it gives us the result and the timeout if it takes too long.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status