Closed julien51 closed 1 year ago
Adding the option to the subgraph seems to be as trivial as adding a config param but will still need a way to detect if something is failing. Not sure how that should be approached exactly? Ping for errors?
The query must also opt-in to querying data with potential inconsistencies through the subgraphError argument. It is also recommended to query _meta to check if the subgraph has skipped over errors, as in the example:
The recommandation is to add an extra param in the queries to detect errors from the client.
Not sure how that should be approached exactly? Ping for errors?
I'd say yes. I'd rather have errors where someone's lock is not working than error where no lock is working? We would make sure to add the required log statements as well?
The recommandation is to add an extra param in the queries to detect errors from the client.
That's a neat feature because we can then hook that to the work that @searchableguy recently did with Sentry and we have a way to detect these?
@julien51 You can use sentry client explicitly to log errors which do not impact the frontend. The way to go would be to return an error field in subgraph service which we use for loading whenever there is an error and log to sentry.
We can ask sentry to post updates whenever there is an error tagged subgraph.
The way the subgraph config works is to add a graphql property _meta { hasIndexingErrors }
to all subgraph requests. That will returns an errors
array. So we check the length of it, and send the error logs to sentry?
also on a sidenote this will cause the decentralized subgraph to crash (fro the docs), so we need a switch to deactivate on mainnet
We now use nonFatalErrors
which is good!
However we need to do this:
The way the subgraph config works is to add a graphql property _meta { hasIndexingErrors } to all subgraph requests. That will returns an errors array. So we check the length of it, and send the error logs to sentry?
assigning to @searchableguy !
We added this in react-query so any errors will be passed from there and a fallback to not affect error from subgraph to load.
Our subgraph is currently configured to "stop working" when there is any indexing error. We can use their
nonFatalErrors
setting to make sure the Subgraph stays up when indexing error occur.Check: https://thegraph.com/docs/en/developing/creating-a-subgraph/#experimental-features