DAOTracker Support

[dOrgJelli]

No description provided.

[dOrgJelli]

@orenyodfat tests are passing. Also I believe I've resolved all comments, please verify.

[dOrgJelli]

@orenyodfat the new DAOTracker contract that contains the arcVersion is integrated. Here's an overview of the new changes:

• Added the ops/templates.json file to keep track of what ABI versions should be used with what mappings.
• Updated generate-contractsInfos.js to...
  setTemplateInfo('ContractName', 'ArcVersion', 'UniqueTemplateName');
  for each templatable ABI. setTemplateInfo(...) is defined in src/utils.ts.
  ex: setTemplateInfo('Avatar', '0.0.1-rc.16', 'Avatar_0_0_1_rc_16');
• Updated generate-subgraph.js to add all possible datasource templates to the subgraph manifest.
• Updated DAOTracker/mapping.ts to use the new way of instantiating templates.

Open question:

• In DAOTracker/mapping.ts, at line # 70, how do you think we should handle the error case where a template isn't found? Should we just fail silently and return from the handler? This essentially means (assuming correct on-chain data) the subgraph is out of date and is missing ABIs + mappings. I propose we add a new entity to the store when this happens, and our automation looks for this entity existing to alerts the team letting them know what's going wrong.

[orenyodfat]

these local vars are redundant here.

[orenyodfat]

need to confirm (somehow) that creating a template for wrong contract does not crash the subgraph .
this can happened only if the event does not come from daocreator.
if we cannot confirm ,so lets consider limit this feature only for daocreator.

[dOrgJelli]

The subgraph does not (as far as I know, looking into this) check to make sure the contract bytecode matches the bytecode in the ABI file. This means that it only watches for events ABIs from a given contract address, and if they do not emit from that address the subgraph will not do anything.

So in the case you're describing, the subgraph would not crash when it creates the template, it would rather just do nothing from there on out. The only case where this could happen is someone wrote custom contracts that emit the events we're looking for, and the subgraph responds to those events from these newly created contracts. The plan here, is that if DAOstack detects a "DAO" is doing this, it would blacklist it.

[dOrgJelli]

Writing a test to verify the subgraph doesn't crash.

[orenyodfat]

as far as I see the only way to mitigate that and stay on the safe side is to track this event only if it come via daocreator. otherwise ignore it.

[orenyodfat]

@orenyodfat the new DAOTracker contract that contains the arcVersion is integrated. Here's an overview of the new changes:

• Added the ops/templates.json file to keep track of what ABI versions should be used with what mappings.
• Updated generate-contractsInfos.js to...
  setTemplateInfo('ContractName', 'ArcVersion', 'UniqueTemplateName');
  for each templatable ABI. setTemplateInfo(...) is defined in src/utils.ts.
  ex: setTemplateInfo('Avatar', '0.0.1-rc.16', 'Avatar_0_0_1_rc_16');
• Updated generate-subgraph.js to add all possible datasource templates to the subgraph manifest.
• Updated DAOTracker/mapping.ts to use the new way of instantiating templates.

Open question:

• In DAOTracker/mapping.ts, at line # 70, how do you think we should handle the error case where a template isn't found? Should we just fail silently and return from the handler? This essentially means (assuming correct on-chain data) the subgraph is out of date and is missing ABIs + mappings. I propose we add a new entity to the store when this happens, and our automation looks for this entity existing to alerts the team letting them know what's going wrong.

this can happened only when the event does not come from daocreator. right ? lets consider supporting this feature only if it come from daocreator.

[dOrgJelli]

@orenyodfat yes this only happens when it comes not from the DAOcreator. I agree that we could limit this to just the DAOcreator for now, and the work done here would still be reusable for when the factories are created.

[dOrgJelli]

@orenyodfat The only DAOs that will be tracked are ones created by the DaoCreator. Additionally the embedded blacklist is implemented in the ops/blacklist.json file.