Handle stranger cases in TokenManager#130
Conversation
Codecov Report
@@ Coverage Diff @@
## master #130 +/- ##
=======================================
Coverage 23.92% 23.92%
=======================================
Files 59 59
Lines 1049 1049
Branches 168 168
=======================================
Hits 251 251
Misses 798 798
Continue to review full report at Codecov.
|
0xGabi
left a comment
0xGabi
left a comment
There was a problem hiding this comment.
Looking good!
An easy fix would be to add this TokenManager's token as a data source, but this would mean a complete re-index of the entire universal subgraph each time an "orphan" token like this is found. Alternatively, cases like this could add the token data source, remove a few other data sources, and deploy their own subgraph.
I think this solution is the easiest but will not scale as I expect a lot of people deploying their own Minime token with the aragonCLI. I think the caching solution you implemented is better.
3 participants
This PR updates the tokens subgraph from v0.1.0 to v0.1.3 (which is stored in the schema, within the AragonInfo object).
This version of the subgraph is being deployed in https://thegraph.com/explorer/subgraph/aragon/aragon-tokens-mainnet right now, and a positive result needs to be tested before this is merged. Otherwise, this PR should not be merged and the subgraph rolled back to v0.1.0.
The stranger case is with the following entities:
Such entities produce a situation where the TokenManager app is not initialized by the time that the subgraph picks it up, and thus does not know its token. This is probably because the DAO was created from the CLI (not a template), and the token deployed and set manually. What's difficult about this situation is that the token will never enter the subgraph via the usual data sources, and thus never be linked to the TokenManager app!
An easy fix would be to add this TokenManager's token as a data source, but this would mean a complete re-index of the entire universal subgraph each time an "orphan" token like this is found. Alternatively, cases like this could add the token data source, remove a few other data sources, and deploy their own subgraph.
However, the way this PR attempts to fix the problem is by adding a new mechanism, where uninitialized TokenManagers are stored in a cache, and whenever a new app is detected in the subgraph, the list of pending-to-be-linked TokenManagers is checked. As soon as one of these can see its token, both are linked and the app is removed from the cache.
We tried triggering the orphan checking upon entering any new block, but unfortunately this makes the subgraph extremely slow. It's a nice feature, but not really production-friendly.