Anna Shaleva

OK, the solution with resulting OID batch size check is not working, we need to allow duplicating entries since containers may have an arbitrary number of blocks with the same...

@AliceInHunterland, review the updated code. Make sure you understand routines-related code. Leave comments if something is not clear or invalid, we'll discuss it then. Move unrelated style changes to separate...

> as we can get oid when putting we can do something like this https://github.com/nspcc-dev/neo-go/commit/a0a0358cb11510911696f1d2ec505f8b6cb7f3c3? It's a separate optimisation, not related to #3647. Create an issue for that, add reference...

And for the current PR in a separate commit replace HEAD with GET to retrieve block index by OID. We'll revert it once https://github.com/nspcc-dev/neofs-node/issues/2988 is fixed.

Here are some more recent logs, we need this issue to be fixed: ``` 2024-10-29 04:04:40.526 Successfully uploaded batch of blocks: from 6590000 to 6597865 2024-10-29 04:33:47.787 failed to update...

BTW, these gaps in the resulting index file (`empty oid found in index file 0`) may still be connected not only with incomplete SEARCH result, but also with some duplicating...

BTW, all these logs about "gaps" belong to a single `neogo-block-uploader-fschain-mainnet.service` instance, and the numbers `91`, `1976`, `16556`, `4257` are repeated, here's a full log tail: [Explore-logs-2024-10-29 08_26_04.txt](https://github.com/user-attachments/files/17553871/Explore-logs-2024-10-29.08_26_04.txt)

To summarize, the reason is that there are duplicating block objects uploaded to the container (@AliceInHunterland you may attach the example). NeoFS session token and block signatures set affect the...

> is not necessary It is necessary for those benchmarks that are expected to end in HALT state. > it runs until it exhaust the gas, As I said in...

> This needs to be in VM limit class. Strictly speaking, it's not a VM limit. Notifications are not a part of VM, they are a part of execution engine.