You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here a simple processor restart solve the problem, but whatever the cause of the problem, processor should be able to recover using its checkpoints, without manual restart.
The text was updated successfully, but these errors were encountered:
poka-IT
changed the title
Subsquid Processor Crash with Missing Blocks Despite Correct DB Entries
Subsquid processor crash with missing blocks despite correct DB entries
Mar 7, 2024
poka-IT
changed the title
Subsquid processor crash with missing blocks despite correct DB entries
Processor crashed with missing blocks despite correct DB entries
Mar 7, 2024
Not sure that caused the error, but blocks weren't missed. More looks like there was some issue on the rpc node side due to that it was unable to return new blocks for a certain period of time, and these 8 blocks weren't printed in the logs because only the last block of the batch is printed.
Regarding to the error itself, it seems that there was a fork/rollback, but processor didn't handle it correctly, will investigate.
My subsquid node processor crashed with this logs:
Error:
[ERR_ASSERTION]: The expression evaluated to a falsy value:\n\n (0, assert_1.default)(head.height >= this.chain[0].height)
It look likes it missed 8 higher blocks, between
435163
and435172
, which is the cause of this error.This indexer is listening a local duniter v2s archive node.
indexer enpoind:
https://gdev-squid.axiom-team.fr/v1/graphql
duniter endpoint:
wss://gdev.p2p.legal/ws
We observe that the problem occurs exactly at midnight, which would be a strange coincidence:
We also notice a gap of 6 minutes and 48 seconds between block 435163 and 435172, whereas only 48 seconds should have passed.
Disturbingly, the missing blocks in the logs seem to be present in the DB, and correctly dated:
Here a simple processor restart solve the problem, but whatever the cause of the problem, processor should be able to recover using its checkpoints, without manual restart.
Version:
"@subsquid/substrate-processor": "^8.1.1"
The text was updated successfully, but these errors were encountered: