rust-lightning/pending_changelog/matt-no-upgrade-skip.txt

## Backwards Compatibility
 * Nodes with pending forwarded HTLCs or unclaimed payments cannot be
   upgraded directly from 0.0.123 or earlier to 0.1. Instead, they must
   first either resolve all pending HTLCs (including those pending
   resolution on-chain), or run 0.0.124 and resolve any HTLCs that were
   originally forwarded or received running 0.0.123 or earlier.
Req the counterparty node id when claiming against a closed chan Currently we store in-flight `ChannelMonitorUpdate`s in the per-peer structure in `ChannelManager`. This is nice and simple as we're generally updating it when we're updating other per-peer data, so we already have the relevant lock(s) and map entries. Sadly, when we're claiming an HTLC against a closed channel, we didn't have the `counterparty_node_id` available until it was added in 0.0.124 (and now we only have it for HTLCs which were forwarded in 0.0.124). This means we can't look up the per-peer structure when claiming old HTLCs, making it difficult to track the new `ChannelMonitorUpdate` as in-flight. While we could transition the in-flight `ChannelMonitorUpdate` tracking to a new global map indexed by `OutPoint`, doing so would result in a major lock which would be highly contended across channels with different peers. Instead, as we move towards tracking in-flight `ChannelMonitorUpdate`s for closed channels we'll keep our existing storage, leaving only the `counterparty_node_id` issue to contend with. Here we simply accept the issue, requiring that `counterparty_node_id` be available when claiming HTLCs against a closed channel. On startup, we explicitly check for any forwarded HTLCs which came from a closed channel where the forward happened prior to 0.0.124, failing to deserialize, or logging an warning if the channel is still open (implying things may work out, but panics may occur if the channel closes prior to HTLC resolution). While this is a somewhat dissapointing resolution, LDK nodes which forward HTLCs are generally fairly well-upgraded, so it is not anticipated to be an issue in practice. 2024-10-09 21:05:18 +02:00			`## Backwards Compatibility`
			`* Nodes with pending forwarded HTLCs or unclaimed payments cannot be`
			`upgraded directly from 0.0.123 or earlier to 0.1. Instead, they must`
			`first either resolve all pending HTLCs (including those pending`
			`resolution on-chain), or run 0.0.124 and resolve any HTLCs that were`
			`originally forwarded or received running 0.0.123 or earlier.`