|
10 | 10 | //! Further functional tests which test blockchain reorganizations. |
11 | 11 |
|
12 | 12 | use crate::sign::{ecdsa::EcdsaChannelSigner, OutputSpender, SpendableOutputDescriptor}; |
13 | | -use crate::chain::channelmonitor::{ANTI_REORG_DELAY, LATENCY_GRACE_PERIOD_BLOCKS, Balance, BalanceSource, ChannelMonitorUpdateStep}; |
| 13 | +use crate::chain::channelmonitor::{ANTI_REORG_DELAY, ARCHIVAL_DELAY_BLOCKS,LATENCY_GRACE_PERIOD_BLOCKS, Balance, BalanceSource, ChannelMonitorUpdateStep}; |
14 | 14 | use crate::chain::transaction::OutPoint; |
15 | 15 | use crate::chain::chaininterface::{ConfirmationTarget, LowerBoundedFeeEstimator, compute_feerate_sat_per_1000_weight}; |
16 | 16 | use crate::events::bump_transaction::{BumpTransactionEvent, WalletSource}; |
@@ -246,31 +246,31 @@ fn archive_fully_resolved_monitors() { |
246 | 246 |
|
247 | 247 | // At this point, both nodes have no more `Balance`s, but nodes[0]'s `ChannelMonitor` still |
248 | 248 | // hasn't had the `MonitorEvent` that contains the preimage claimed by the `ChannelManager`. |
249 | | - // Thus, calling `archive_fully_resolved_channel_monitors` and waiting 4032 blocks will not |
250 | | - // result in the `ChannelMonitor` being archived. |
| 249 | + // Thus, calling `archive_fully_resolved_channel_monitors` and waiting `ARCHIVAL_DELAY_BLOCKS` |
| 250 | + // blocks will not result in the `ChannelMonitor` being archived. |
251 | 251 | nodes[0].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
252 | 252 | assert_eq!(nodes[0].chain_monitor.chain_monitor.list_monitors().len(), 1); |
253 | | - connect_blocks(&nodes[0], 4032); |
| 253 | + connect_blocks(&nodes[0], ARCHIVAL_DELAY_BLOCKS); |
254 | 254 | nodes[0].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
255 | 255 | assert_eq!(nodes[0].chain_monitor.chain_monitor.list_monitors().len(), 1); |
256 | 256 |
|
257 | | - // ...however, nodes[1]'s `ChannelMonitor` is ready to be archived, and will be in exactly 4032 |
258 | | - // blocks. |
| 257 | + // ...however, nodes[1]'s `ChannelMonitor` is ready to be archived, and will be in exactly |
| 258 | + // `ARCHIVAL_DELAY_BLOCKS` blocks. |
259 | 259 | nodes[1].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
260 | 260 | assert_eq!(nodes[1].chain_monitor.chain_monitor.list_monitors().len(), 1); |
261 | | - connect_blocks(&nodes[1], 4031); |
| 261 | + connect_blocks(&nodes[1], ARCHIVAL_DELAY_BLOCKS - 1); |
262 | 262 | nodes[1].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
263 | 263 | assert_eq!(nodes[1].chain_monitor.chain_monitor.list_monitors().len(), 1); |
264 | 264 | connect_blocks(&nodes[1], 1); |
265 | 265 | nodes[1].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
266 | 266 | assert_eq!(nodes[1].chain_monitor.chain_monitor.list_monitors().len(), 0); |
267 | 267 |
|
268 | 268 | // Finally, we process the pending `MonitorEvent` from nodes[0], allowing the `ChannelMonitor` |
269 | | - // to be archived 4032 blocks later. |
| 269 | + // to be archived `ARCHIVAL_DELAY_BLOCKS` blocks later. |
270 | 270 | expect_payment_sent(&nodes[0], payment_preimage, None, true, false); |
271 | 271 | nodes[0].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
272 | 272 | assert_eq!(nodes[0].chain_monitor.chain_monitor.list_monitors().len(), 1); |
273 | | - connect_blocks(&nodes[0], 4031); |
| 273 | + connect_blocks(&nodes[0], ARCHIVAL_DELAY_BLOCKS - 1); |
274 | 274 | nodes[0].chain_monitor.chain_monitor.archive_fully_resolved_channel_monitors(); |
275 | 275 | assert_eq!(nodes[0].chain_monitor.chain_monitor.list_monitors().len(), 1); |
276 | 276 | connect_blocks(&nodes[0], 1); |
|
0 commit comments