There is some situation where a timeout can happen and be reported as a deterministic error, as these logs indicate:
2022-05-20 01:08:59
May 20 01:08:59.492 DEBG Subgraph stopped, WASM runtime thread terminated, sgd: 300247, subgraph_id: QmTpWTHihFbE9tgz1BE6QaJEQk9GXkzGENeF7AEheriu8J, component: SubgraphInstanceManager
2022-05-20 01:08:59
May 20 01:08:59.490 ERRO Subgraph instance failed to run: Failed to call 'asc_type_id' with 'String' wasm backtrace: 0: 0x2622 - <unknown>!generated/schema/Epoch#get:id 1: 0x3662 - <unknown>!generated/schema/GlobalState#get:networkArrayHead 2: 0x45bf - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type : wasm trap: interrupt wasm backtrace: 0: 0xffffffff - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/allocate 1: 0x2622 - <unknown>!generated/schema/Epoch#get:id 2: 0x3662 - <unknown>!generated/schema/GlobalState#get:networkArrayHead 3: 0x45bf - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type in handler `handleCrossChainEpochOracle` at block #12069788 (5a725bbd871dc2a2174d7da4e777fa2efb17f4725a51f51dbc15e5fc6b6fe836), code: SubgraphSyncingFailure, sgd: 300247, subgraph_id: QmTpWTHihFbE9tgz1BE6QaJEQk9GXkzGENeF7AEheriu8J, component: SubgraphInstanceManager
2022-05-20 01:08:59
May 20 01:08:59.073 ERRO Subgraph error 1/1, code: SubgraphSyncingFailure, error: Failed to call 'asc_type_id' with 'String' wasm backtrace: 0: 0x2622 - <unknown>!generated/schema/Epoch#get:id 1: 0x3662 - <unknown>!generated/schema/GlobalState#get:networkArrayHead 2: 0x45bf - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type : wasm trap: interrupt wasm backtrace: 0: 0xffffffff - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/allocate 1: 0x2622 - <unknown>!generated/schema/Epoch#get:id 2: 0x3662 - <unknown>!generated/schema/GlobalState#get:networkArrayHead 3: 0x45bf - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type in handler `handleCrossChainEpochOracle` at block #12069788 (5a725bbd871dc2a2174d7da4e777fa2efb17f4725a51f51dbc15e5fc6b6fe836), block_hash: 0x5a725bbd871dc2a2174d7da4e777fa2efb17f4725a51f51dbc15e5fc6b6fe836, block_number: 12069788, sgd: 300247, subgraph_id: QmTpWTHihFbE9tgz1BE6QaJEQk9GXkzGENeF7AEheriu8J, component: SubgraphInstanceManager
2022-05-20 01:08:59
May 20 01:08:59.073 INFO Applying 1 entity operation(s), block_hash: 0x5a725bbd871dc2a2174d7da4e777fa2efb17f4725a51f51dbc15e5fc6b6fe836, block_number: 12069788, sgd: 300247, subgraph_id: QmTpWTHihFbE9tgz1BE6QaJEQk9GXkzGENeF7AEheriu8J, component: SubgraphInstanceManager
2022-05-20 01:08:58
May 20 01:08:58.769 INFO Done processing trigger, gas_used: 26562157793948, data_source: DataEdge, handler: handleCrossChainEpochOracle, total_ms: 1202248, transaction: 0xc391…35d7, to: 0xae6a…6836, function: crossChainEpochOracle(bytes), sgd: 300247, subgraph_id: QmTpWTHihFbE9tgz1BE6QaJEQk9GXkzGENeF7AEheriu8J, component: SubgraphInstanceManager
2022-05-20 01:08:56
May 20 01:08:56.579 ERRO Handler skipped due to execution failure, error: Failed to call 'asc_type_id' with 'String' wasm backtrace: 0: 0x2622 - <unknown>!generated/schema/Epoch#get:id 1: 0x3662 - <unknown>!generated/schema/GlobalState#get:networkArrayHead 2: 0x45bf - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type : wasm trap: interrupt wasm backtrace: 0: 0xffffffff - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/allocate 1: 0x2622 - <unknown>!generated/schema/Epoch#get:id 2: 0x3662 - <unknown>!generated/schema/GlobalState#get:networkArrayHead 3: 0x45bf - <unknown>!node_modules/@graphprotocol/graph-ts/global/global/id_of_type , handler: handleCrossChainEpochOracle, sgd: 300247, subgraph_id: QmTpWTHihFbE9tgz1BE6QaJEQk9GXkzGENeF7AEheriu8J, component: SubgraphInstanceManager
The latest version of wasmtime no longer supports these interrupts but has other ways to support timeouts. So upgrading wasmtime would likely make timeout handling more robust and possibly avoid this issue.
There is some situation where a timeout can happen and be reported as a deterministic error, as these logs indicate:
The latest version of wasmtime no longer supports these interrupts but has other ways to support timeouts. So upgrading wasmtime would likely make timeout handling more robust and possibly avoid this issue.