Syncer: Logic for conditional broadcast

[TheCharlatan]

This delays a transaction broadcast to after a certain block height has been reached.

This allows patterns as described in the CCS: "swap-daemon can queue tasks such as execute refund path at block height X with a chain-syncer."

[h4sh3d]

If I got it right the current logic always wait on a new block to trigger the broadcast even if the the height is smaller to current height. I get that the height should always be in the future but I wouldn't rely on this assumption. (In its current form is fine as we always use None but one might be tricked in the future)

[TheCharlatan]

If I got it right the current logic always wait on a new block to trigger the broadcast even if the the height is smaller to current height.

It does trigger the iterator, but there is still a height check during the iteration. I wanted to keep the changes to the logic as minimal as possible here, but if you think this is too wasteful, I'd gladly refactor.

[h4sh3d]

Whops I think I explained badly what my concern is. When a transaction broadcast arrives in syncer and the broadcast has an height attached we don't check if it is already broadcastable.

I'd see something like

if les Some(height) = task.broadcast_after_height {
    if height < current_height {
        // bradocast now
    } else {
        // add to pending
    }
} else { ... }

Or I didn't understand your explanation and you can forget all of this :)

Otherwise this LGTM!

[TheCharlatan]

Whops I think I explained badly what my concern is. When a transaction broadcast arrives in syncer and the broadcast has an height attached we don't check if it is already broadcastable.

Ah, now I go it! Yes, that's a silly limitation. I was thinking the producer of a broadcast task would naturally be subscribed to the block height, but that is not exactly defensive. I'll add some code to check the height when the task comes in and immediately broadcast it in case we already surpassed it.