When an `std::future::Future` is `poll()`ed, we're only supposed to
use the latest `Waker` provided. However, we currently push an
`StdWaker` onto our callback list every time `poll` is called,
waking every `Waker` but also using more and more memory until the
`Future` itself is woken.
Here we take a step towards fixing this by giving each `Future` a
unique index and storing which `Future` an `StdWaker` came from in
the callback list. This sets us up to deduplicate `StdWaker`s by
`Future`s in the next commit.
In the next commit we'll fix a memory leak due to keeping too many
`std::task::Waker` callbacks in `FutureState` from redundant `poll`
calls, but first we need to split handling of `StdWaker`-based
future wake callbacks from normal ones, which we do here.
In order to continuously monitor our dependencies for security
vulnerabilities, we introduce a new CI job that will use `cargo audit`
to check for any known vulnerabilities.
This job is run on a daily schedule. For each new advisory, a new issue
will be created.
.. as the `electrsd` crate doesn't support it.
While we previously did so in our CI script, we now also `cfg`-gate the
tests and dependencies for easier handling.
Preallocate for 8 items in the vec. I chose this value for
1. features
2. description
3. payment hash
4. expire time
5. min_final_cltv
6. payment secret
7. route hint
8. for the memes
As part of the ongoing async signer work, our holder signatures must
also be capable of being obtained asynchronously. We expose a new
`ChannelMonitor::signer_unblocked` method to retry pending onchain
claims by re-signing and rebroadcasting transactions. Unfortunately, we
cannot retry said claims without them being registered first, so if
we're not able to obtain the signature synchronously, we must return the
transaction as unsigned and ensure it is not broadcast.
This method is meant to be used as a last resort when a user is forced
to broadcast the current state, even if it is stale, in an attempt to
claim their funds in the channel. Previously, we'd return the commitment
and HTLC transactions such that they broadcast them themselves. Doing so
required a different code path, one which was not tested, to obtain
these transactions than our usual path when force closing. It's not
worth maintaining both, and it's much simpler for us to broadcast
instead.
The whole point of full_stack_target is to just expose our entire
API to the fuzzer and see what happens. Sadly, we're really only
exposing a small subset of our API. This improves that by exposing
a handful of other assorted methods from ChannelManager and
PeerManager.
A client node might choose not to handle `Event::BumptTransaction`
events and leave bumping / Anchor output spending to a trusted
counterparty.
However, `Event::BumptTransaction` currently doesn't offer any clear
indication what channel and/or counterparty it is referring to. In order
to allow filtering these events, we here expose the `channel_id` and
`counterparty_node_id` fields.
This exposes details around pending HTLCs in ChannelDetails. The state
of the HTLC in the state machine is also included, so it can be
determined which protocol message the HTLC is waiting for to advance.
