|
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