Closed anmode closed 1 year ago
@sr-gi review, please!
If you'd like me to review a PR hit the request button and be patient.
If you'd like me to review a PR hit the request button and be patient.
So sorry! I'll remember. Actually, I tried but I can't add reviewer
This is not the right way to fix the issue.
Here, you are:
- Defining a flag that is always hardcoded to
true
. What's the point of that?- Breaking the intention when the block is not found, which will result in vectors with a size different from the expected one, meaning that the cache won't have the desired length.
Having in mind the maximum a node can be pruned is up to
550MiB
, the is no way we can face this issue due to having reached the last block our node is aware of as long as our tower is up to date. Meaning the only way of hitting this error is by trying to turn on a tower that has fallen behind many blocks. Therefore, the real solution does not involve stopping when a block cannot be found, but either shifting the block window forward so we can get enough blocks, or directly starting from the most recent tip, potentially missing some of the appointment transitions. Also, this has to be configurable by the user, not a hardcoded flag.Please, before submitting a PR do test out if you can actually accomplish what you are trying locally.
Ohh okay, I got the point! Thank you very much. Got to know new information ok! I'll update.
@anmode you may be interested in checking #216 to see what the approach we were aiming for looked like
@anmode you may be interested in checking #216 to see what the approach we were aiming for looked like
sure! I see... it was a nice approach
Fixes #209