diff options
| author | fanquake <fanquake@gmail.com> | 2023-07-26 09:58:47 +0100 |
|---|---|---|
| committer | fanquake <fanquake@gmail.com> | 2023-07-26 10:19:56 +0100 |
| commit | f033a981ed72ceab8133ccddc6d99cd0d4b2d707 (patch) | |
| tree | b50b4038ca8a51726f69a57a1426d243e3f49eb7 /doc | |
| parent | c2ff87e1fa35e1edfa434ac6f341a141d3545257 (diff) | |
| parent | c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c (diff) | |
| download | bitcoin-f033a981ed72ceab8133ccddc6d99cd0d4b2d707.tar.xz | |
Merge bitcoin/bitcoin#28139: test: create wallet specific for test_locked_wallet case
c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c test: create wallet specific for test_locked_wallet case (furszy)
Pull request description:
Coming from https://github.com/bitcoin/bitcoin/pull/28089#discussion_r1265478128.
Several test cases are relying on the node1 default wallet, which thanks to 'test_locked_wallet' is encrypted.
And can be only accessed within a specific timeframe (100ms), a duration internally set by the same test.
This situation introduces a potential race condition, where other tests must complete their operations within
the specified 100ms window to pass (otherwise the wallet gets re-locked and they fail).
This can be seen running the test in valgrind (https://github.com/bitcoin/bitcoin/pull/28089), where other test cases fail due the wallet re-locking
itself after the 100ms.
ACKs for top commit:
MarcoFalke:
lgtm ACK c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c
ishaanam:
utACK c648bdbda21c7ae90c6b40e506ca4ed62b1dbb6c
Tree-SHA512: 01cde5a4a0cb3405adb9ea3c1f73841f3fa237d1162268ed06f0d49ca38541006b423a029e0b5e5955e1aa7e018c4600d894e555a68cf17ff60a4b8be58f4aa9
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions