SeedyROM
commented
2 years ago This is in a while loop, and if a block variable comes in with an error, we're instructing the application to throw an error and exit.
This is simply not the case, we're exiting the current loop and passing an Err enum variant up the callstack. This can be handled by anyone further up the chain who wants to handle it, and we do!
We handle the error, tell the user we got it and what it was. Then we retry getting more blocks from the chain, if we miss a block or 2 (which can absolutely happen considering the connection goes down 4 times a day) this task picks up the slack: https://github.com/CronCats/croncat-indexer/blob/feb6eea20f1d0680fb6cde2a71d58d2aadefa03d/src/indexer/system.rs#L228-L252
Which once again, handles intermittent errors and retries if it fails.
I think we might need to be careful about using the
?operator for long-running tasks like the agent and indexer.This is a pretty good rundown: https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#a-shortcut-for-propagating-errors-the--operator
It's basically like, "something happened that means we gotta stop"
In the function below, for instance, here's an example:
https://github.com/CronCats/croncat-indexer/blob/feb6eea20f1d0680fb6cde2a71d58d2aadefa03d/src/streams/block.rs#L84
This is in a while loop, and if a
blockvariable comes in with an error, we're instructing the application to throw an error and exit.I think we'll need to replace this with a
matchstatement that checks forOkorErrand on error, perhaps log it (optional) or justcontinueon with the while loop.I see in that same function
ws_block_streamthere are a few more places where we have the pattern to throw an error and crash the program, but I think those also need to be dealt with in a way that doesn't stop execution.