wallet: Logprint the start of a rescan #12925

pull jonasschnelli wants to merge 1 commits into bitcoin:master from jonasschnelli:2018/04/rescan changing 1 files +3 −0

jonasschnelli commented at 4:52 PM on April 9, 2018: contributor

Right now, there is no log entry when a rescan starts which is confusing especially when a "still rescanning" log entry appears after the log-update timeout of 60s or when user manually aborts the rescan.

This PR adds a log entry when a rescan starts.
Logprint the start of a rescan cab0824c96
jonasschnelli added the label Wallet on Apr 9, 2018
ryanofsky commented at 4:55 PM on April 9, 2018: member

utACK cab0824c96e2433a29d5e730f0e888a0a00f9eb3
practicalswift commented at 8:52 PM on April 9, 2018: contributor

utACK cab0824c96e2433a29d5e730f0e888a0a00f9eb3
MarcoFalke renamed this:
~~[Trivial] Logprint the start of a rescan~~
wallet: Logprint the start of a rescan
on Apr 9, 2018

MarcoFalke commented at 11:17 PM on April 9, 2018: member

I think you can now remove the line from CWallet::CreateWalletFromFile:

LogPrintf("Rescanning last %i blocks (from block %i)...\n", chainActive.Height() - pindexRescan->nHeight, pindexRescan->nHeight);

in src/wallet/wallet.cpp:1718 in cab0824c96
```
1713 | @@ -1714,6 +1714,9 @@ CBlockIndex* CWallet::ScanForWalletTransactions(CBlockIndex* pindexStart, CBlock
1714 |  
1715 |      CBlockIndex* pindex = pindexStart;
1716 |      CBlockIndex* ret = nullptr;
1717 | +
1718 | +    if (pindex) LogPrintf("Rescan started from block %d...\n", pindex->nHeight);
```
laanwj commented at 11:47 AM on April 10, 2018:

If !pindex, doesn't that mean Rescan started from block 0...?

promag commented at 11:39 PM on April 10, 2018:

No, if !pindex the loop below won't run.

promag commented at 11:39 PM on April 10, 2018:

Nit, could use pindexStart instead so it's more obvious?

laanwj commented at 6:43 AM on April 11, 2018:

Nah it's fine, I was just confused then, it looked a bit strange to conditionally log this message.

jonasschnelli commented at 6:48 AM on April 11, 2018:

Indeed. I just want to prevent a nullptr access in case of stupid future changes (not possible now).

Empact commented at 8:13 AM on April 11, 2018:

Nit: I'd be down for an early return based on pIndexStart being null, given in that case all else is irrelevant.

laanwj commented at 2:20 PM on April 11, 2018:

@empact Right that seems like a clear solution, though we can do that later, this has enough utACKs I'm going to merge now.
promag commented at 11:40 PM on April 10, 2018: member

utACK cab0824.
kallewoof commented at 9:08 AM on April 11, 2018: member

utACK cab0824c96e2433a29d5e730f0e888a0a00f9eb3
laanwj merged this on Apr 11, 2018
laanwj closed this on Apr 11, 2018
laanwj referenced this in commit 6d3de17a22 on Apr 11, 2018
PastaPastaPasta referenced this in commit 0d22818d93 on Jun 10, 2020
PastaPastaPasta referenced this in commit 5a4add2328 on Jun 10, 2020
PastaPastaPasta referenced this in commit 16a5a4bde2 on Jun 10, 2020
PastaPastaPasta referenced this in commit caf0ff73d3 on Jun 11, 2020
PastaPastaPasta referenced this in commit fe6c66c1de on Jun 11, 2020
PastaPastaPasta referenced this in commit 8a6d86e028 on Jun 11, 2020
PastaPastaPasta referenced this in commit 848f60b626 on Jun 12, 2020
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels