Some `Listen` implementations assert that each block is exactly after the previous

[TheBlueMatt]

I think at least the sweeper, but we're supposed to allow back-to-back connections of the same block with more txn.

[tnull]

but we're supposed to allow back-to-back connections of the same block with more txn.

Not sure I follow what this means. Aren't we supposed to always give the full block in Listen?

[TheBlueMatt]

No? https://docs.rs/lightning/latest/lightning/chain/trait.Listen.html#tymethod.filtered_block_connected

[tnull]

No? https://docs.rs/lightning/latest/lightning/chain/trait.Listen.html#tymethod.filtered_block_connected

But the API contract so far still has been that you supply all relevant transactions of a block as defined by Filter in one go, no?

[TheBlueMatt]

Sure, but the Filter may update during a block-connected call, and then the call has to be made again with what is now the relevant transaction set. This has always been the case (with the one exception that if you provide all dependencies of matched transactions recursively you don't need to worry about it).

[tnull]

Sure, but the Filter may update during a block-connected call, and then the call has to be made again with what is now the relevant transaction set. This has always been the case (with the one exception that if you provide all dependencies of matched transactions recursively you don't need to worry about it).

Hmm, probably best to resume the discussion over on #3876 (comment) then, because if that's the case IMO we should see how we can fix that. To me this requirement seems to complicate the Filter/Listen implementations quite a bit, i.e., you can't process the subscribed txids/outputs in rounds anymore, but you'd constantly have to double-check if something changed mid-processing, which likely would also have some performance impact?

[TheBlueMatt]

I don't see why we need to block #3876 on making an unrelated further change to Filter/Listen? But I also don't see how we can possibly change this requirement. We could only document the "provide all dependencies of matched transactions in a block recursively" option, but that isn't practical in some cases, and will lead to re-scanning anyway, so we might as well tell them they can rescan based on Filter.