The problem comes from merkleTreeRoot == merkleTreeLevels[-1][0] verification on verifier side.
Maybe if meta.py could give us the ratio of failure it could help us guess the issue.
Reproducibility:
```sh
./verifier.py 8c6131cb2fecbb8e6468b295f44ff95ab6410e1e8726eb1ff7bc970c689f7f73 163b27578d8efd1171501bf814cc0eb5d6709d02215e292938c45a0320b9b640 '{2788, 2053, 2664, 1033, 3672, 428, 1357, 3406, 2799, 2003, 2900, 3903, 3768, 3643, 1116, 3325, 3167, 1183}'
```
The problem comes from `merkleTreeRoot == merkleTreeLevels[-1][0]` verification on verifier side.
Maybe if `meta.py` could give us the ratio of failure it could help us guess the issue.
The issue was due to ast.literal_eval(str(indexesRequest)) not being idempotent in terms of order preservation (as set is unordered) with indexesRequest being a set.
The issue was due to `ast.literal_eval(str(indexesRequest))` not being idempotent in terms of order preservation (as `set` is unordered) with `indexesRequest` being a `set`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Reproducibility:
The problem comes from
merkleTreeRoot == merkleTreeLevels[-1][0]verification on verifier side.Maybe if
meta.pycould give us the ratio of failure it could help us guess the issue.The issue was due to
ast.literal_eval(str(indexesRequest))not being idempotent in terms of order preservation (assetis unordered) withindexesRequestbeing aset.