We add `CandidateRouteHop::source` and
`CandidateRouteHop::source` functions to point
to current and next hops in route respectively.
As we have now `source` and `target`
available in `CandidateRouteHop` we also
remove `CandidateRouteHop::id` inputs
so now they are consumed from `self.target`
and `self.source` functions.
In the `add_entry` macro we also remove `source`
and `target` arguments in favor of `candidate`
of type `CandidateRouteHop` that holds the
needed info.
If `outband` flag is set to true then `ChannelInfo::node_one`
is forwarding a payment to target `ChannelInfo::node_two`.
If `outband` flag is set to false then `ChannelInfo::node_two`
is forwarding a payment to target `ChannelInfo::node_one`.
The VLS signer has a desire to see preimages for resolved forwarded
HTLCs when they are first claimed by us, even if that claim was for
the inbound edge (where claiming strictly increases our balance).
Luckily, providing that information is rather trivial, which we do
here.
Fixes#2356
Users are often confused when we fail to find a route due to some
requirements on the first hop are not being met. While we now take note
and log such candidates, we still previously required users to check
additional details to figure out why exactly the router refused to route
over a particular first hop.
Here, we add additional TRACE logging, in particular for
`ChannelDetails::next_outbound_htlc_limit_msat` and
`ChannelDetails::next_outbound_htlc_minimum_msat` when they are
relevant.
The `WithChannelMonitor` log decorator redundantly locks the
`ChannelMonitor` inner mutex, which we fix here, as well as add a
new constructor which avoids locking at all if an inner mutex lock
is already readily available.
df3ab2ee27 was rebased one too many
times and ended up reverting some of the `log_bytes!()` removals
around types which now implement `Display` in `ChannelManager`.
This commit removes those, as well as one additoinal excess macro
which slipped in somewhere else.
e21a500668 cleaned up the error
handling in `ChainMonitor::update_channel` a bit, but accidentally
replaced the deliberate panic with a hang. This commit ensures we
properly drop the monitors read lock before taking a write lock.
Now that `ChannelMonitor` is careful about wrapping `Logger`s at
the edge, there's no need to use `WithChannelMonitor` in a few
cases in `channel.rs` and one in `channelmanager.rs`.
In order to ensure log lines generated by `ChannelMonitor` always
have a counterparty and channel ID entry, this consistently wraps
`Logger`s in a decorator in all `pub(X)` `ChannelMonitor` functions,
removing `pub` markings on `ChannelMonitorImpl` methods that aren't
actually publicly reachable anyway.
This also lets us clean up the `Logger` types in various
`ChannelMonitor` methods.
There are various place where we log something related to a channel
but fail to fill in the channel's counterparty information. This is
somewhat surprising, given channel counterparty information is
always known, but simply is sometimes not readily accessible to LDK
when a log is printed.
973636bd2a introduced a new `HashMap`
in the `TestLogger` but then did lookups by iterating the entire
map. This fixes that, and also takes this opportunity to stop
allocating new `String`s for the module to store each log entry in
the `TestLogger`
Move the handling of ChannelMonitorUpdateStatus::UnrecoverableError to
the point of error to avoid needing an unwrap later when re-wrapping the
logger.
Include optional peer and channel ids to logger::Record. This will be
used by wrappers around Logger in order to provide more context (e.g.,
the peer that sent a message, the channel an operation is pertaining to,
etc.). Implementations of Logger can include this as metadata to aid in
searching logs.
While its all constant arithmetic to calculate the shift, which
LLVM likely optimizes out for us, there's no reason to do it four
times, which just makes the code harder to read.
