To allow code with more up-to-date dependencies to import loop, we
bump our lndclient version. The minimum loop version remains 11.1
since we're not using any new apis.
This makes two changes to handling of errors when configuration file
could not be loaded:
1. Only NotFound errors are considered OK - access errors and other FS
issues are now treated as fatal.
2. Failing to load config file specified explicitly via `--configfile`
option is alway a fatal error.
Rationale: If the configfile was specified explicitly then it indicates
the user really wishes to load it. While the user could want it to be
optionally loaded for extra configuration options, this can be
accomplished using an empty file.
If the config file was not specified explicitly then its' path was
computed from loop directory. If the file is inaccessible due to
permissions or other FS errors it's nearly certain other following
operations will fail as well. Failing early with a clear message is thus
beneficial.
This still leaves room for uncaught user error (e.g. mistakenly naming
config file inside loop dir as `loop.conf` instead of `loopd.conf`) but
it's greatly reduced and such error should be easier to identify.
(Indirectly) closes#412
In this commit we add a call to the new probe endpoint directly into the
loop-in quote call. Furthermore we add an option to include private
channels in the loopin swap payment request. This is also useful for when
users quote/probe directly using the client API and specify hop hints.
Formatting our error was stifling any grpc error returned by the
server. Instead, we bubble up our grpc error, setting an unknown
code if the server did not specifically return an error code.
Add a new failure state that the server may send to the client.
This state is sent for loop in swaps where the client has
erroneously published multiple outputs for a loop in swap (this
could happen if an end user created an external tx with too many
outputs). Failing the swap server side protects users from potential
footguns where they publish the hltc then the server can claim more
money than was paid out off chain. This can never happen when the
loop client publishes the htlc because it only ever contains one
output.
There is an open issue for Python gRPC clients that is
currently being debugged grpc/grpc#23172
It can be mitigated server-side by specifying h2 in the metadata header.
From lnd 0.13.0, the SubscribeSingleInvoice rpc will return an EOF
once it has served a final state to the stream. This is handled in
our lndclient wrapper by closing the channels that we send updates/
errors on. When we are exclusively consuming updates from these
streams, we don't need to handle this case because we will receive
our final update and exit. However, in the case where we continue
to listen on the update channels after consuming the final update,
we need to handle this EOF/closed channels case. This is done by
setting the channels to nil after they're closed so that we no
longer select on them but can continue waiting for our other cases
to complete.
We have similar handling in loopout's waitForHtlcSpendConfirmed.
