Bad pruning in Receipt domain at the end of the million

[JkLondon]

after pruning smth happening with Receipt domain at block 16999999
Symptom of it - getLogs response with wrong indexes (main)
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method": "eth_getLogs","params": [ {"fromBlock": "0x103663f", "toBlock": "0x103663f"} ], "id":1}' -s localhost:8546
part of response from main

result": [
        {
            "address": "0x5df7511872ba85626cf1ccedbcefc347edc2375e",
            "blockHash": "0xe464691f28218637d00ac4d694a86c0e01044b0a76b357b997e575be6d4cc135",
            "blockNumber": "0x103663f",
            "data": "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
            "logIndex": "0x11c",
....

part of response from quicknode (for reference)

"result": [
        {
            "address": "0x5df7511872ba85626cf1ccedbcefc347edc2375e",
            "blockHash": "0xe464691f28218637d00ac4d694a86c0e01044b0a76b357b997e575be6d4cc135",
            "blockNumber": "0x103663f",
            "data": "0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
            "logIndex": "0x0",
....

More light on the reason:
bad indexes come from ReceiptGetAsOf function that works well on DB and most of the files. But at the end of the million (Now I have only this example) values from all 16999999th block's txnums are overwritten.

[AskAlexSharov]

status: fixed by #13052 - but re-generating files on snapshotters now

[AskAlexSharov]

done for all chains except gnosis (maybe will finish in 1 week)

[AskAlexSharov]

released all chains