address cache run two times

[buhtignew]

I've run address cache mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik twice while the blockchain hasn't moved ahead and the second time I've got the following error:

Storing blockheight locators for addresses: ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik']
You have reached the tip of the blockchain.
 
Error: Start block is after the current block height.

_
This is probably related:
If I run transaction list -x -o mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -l -t or transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l -t or transaction list mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -x -l or transaction list -x -o mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik -l after I've already run one of them with the local slimcoind still on the same blockheight I'm getting General error raised by PeerAssets. Check if your input is correct.

[d5000]

This is expected. If the current blockheight is X, and the blockchain doesn't move before you enter this command again, then the startblock will be X+1, and the current blockheight is still X. It does of course not make sense to cache anything in this situation.

I have modified the message however a bit, so it's clearer for the user. Will be uploaded with next commit.

About the other errors: Try them again with the updated code (see issue #86), they may be fixed now. If not, please provide me the output with -d/--debug flag.

If everything works please close.

[buhtignew]

The second issue is solved. There is no error message since the command is not caching anything, just providing results of the caching already done.

I think in case of the first issue we should do in the same way - there is really no error to report in case the blockchain hasn't moved yet.
So, IMO, we shouldn't output the error message that is being output at the moment:

Error: Start block is after the current block height.
If you didn't specify a start block, this probably means there are no new blocks to cache.

since no start block hasn't been selected.
Thus without making any caching we may output the same as if the scanning was successful, i.e. the same output of the previous scanning, for instance:

Storing blockheight locators for addresses: ['mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik']
Processing block: 464300
You have reached the tip of the blockchain.
Stored block data until block 464322 with hash 8c8074568c69dd44851bf024d38aac81f80f9ae06d54c61abcfec531a067a8c4 .
Block heights for the checked addresses: {'mkwJijAwqXNFcEBxuC93j3Kni43wzXVuik': [132356, 141256, 149190, 150340, 150374, 155588, 156516, 156875, 156877, 156883, 156889, 156891, 156893, 156895, 156899, 156901, 157618, 158957, 159434, 159718, 159801, 162591, 163417, 163424, 163432, 164184, 164194, 164648, 165461, 166566, 169325, 174137, 177498, 177655, 177992, 190206, 203607, 364760, 364793, 364806, 364881, 364893, 381560, 445930, 445940, 445944, 445945, 446677, 447458, 447628, 447635, 447961, 447964, 447967, 447985, 449109, 451439, 451444, 454036, 454060, 454248, 454268, 454287, 454292, 454297, 454300, 454302, 454343, 455622]}
Storing new locator block heights.

Maybe without the last line.
Would it make sense/be possible?

[d5000]

Current solution is serviceable. To show the current block heights the command config show ADDRESS -b exists. And probably nobody will ever see this error.

I'm closing.