43aed386bc33f8dfca53ea2ec166dea1ce3d42d3 esplora: also test the gap limit bounds in the async client (Antoine Poinsot)
cb713e5b8c74181518e8cfcd4095c862bc73f014 esplora: also fix the gap limit check in the async client (Antoine Poinsot)
2c4e90a76fea51cb7381242f55b1ca0f02e20d4e esplora: scan gap limit bounds testing (Antoine Poinsot)
18bd3296170e64aee6870cd96dde52a0078bbcb1 esplora: fix incorrect gap limit check in blocking client (Antoine Poinsot)
Pull request description:
The gap limit was checked such as if the last_index was not None but the last_active_index was, we'd consider having reached it. But the last_index is never None for this check. This effectively made it so the gap limit was always 1: if the first address isn't used last_active_index will be None and we'd return immediately.
Fix this by avoiding error-prone Option comparisons and correctly checking we've reached the gap limit before breaking out of the loop.
ACKs for top commit:
danielabrozzoni:
ACK
43aed386bc33f8dfca53ea2ec166dea1ce3d42d3
evanlinjin:
ACK
43aed386bc33f8dfca53ea2ec166dea1ce3d42d3
Tree-SHA512: c6a172e0627380add56aec79e7fe36c0358e092b59f0bea8885d3524e65c10336291943efe6aeb5cc83f90c4f2146ed63215e56e08583d703b6ab57284487f03