Incorrect entities in DB

[bohendo]

Do you want to request a feature or report a bug?
Bug

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

Transaction 0x53e7d9ce8d9c032e87b15310cc74ec46a2e5e085ced2bf8333b60b7f1aecd768 makes a good case study of this problem. You'll see from the event logs that this proposal's id is "0x2c766d6d269d8cef520aeaf4e78bed2db4cb59ed07330e203dcafe50f4a637f1"

The mappings that generated this data can be found here but the most interesting file are probably the GenesisProtocol handlers and the schema.

The above source code should compile to a subgraph that can be found at /ipfs/QmQ1rhZhZQeSm4mgR8Bnii6xq7efBFqMXpd82cNLZq7Hhh, the same subgraph that's in the subgraph column of the db row displayed below.

Running a query to fetch this proposal's data in the database returns:

$ select data from entities where entity = 'Proposal' and id = '0x2c766d6d269d8cef520aeaf4e78bed2db4cb59ed07330e203dcafe50f4a637f1';

{
  "id": {
    "data": "0x2c766d6d269d8cef520aeaf4e78bed2db4cb59ed07330e203dcafe50f4a637f1",
    "type": "String"
  },
  "dao": {
    "data": "0xa3f5411cfc9eee0dd108bf0d07433b6dd99037f1",
    "type": "String"
  },
  "time": {
    "data": "1542255067",
    "type": "BigInt"
  },
  "type": {
    "data": "genesisProtocolBounty",
    "type": "String"
  },
  "state": {
    "data": 3,
    "type": "Int"
  },
  "voter": {
    "data": "0xf47c189056ab295854e4752f3dc61e1800793d56e500a97efabd1e281ddbd1c1",
    "type": "String"
  },
  "amount": {
    "data": "75000000000000000000",
    "type": "BigInt"
  },
  "staker": {
    "data": "0xf47c189056ab295854e4752f3dc61e1800793d56e500a97efabd1e281ddbd1c1",
    "type": "String"
  },
  "account": {
    "data": "0xd04120c5ed3c1d141a40fcec9ea37a4828efbd73ba259cdfa9e1818133942808",
    "type": "String"
  },
  "address": {
    "data": "0xda666fb849cfa3c44540c9a8897a49dea7e74d83",
    "type": "Bytes"
  },
  "decision": {
    "data": "1",
    "type": "BigInt"
  },
  "proposal": {
    "data": "0xa8b21f86775c02be6ed8a4c967a5006b9829ad347355c51a8ea30d8d4a1f894a",
    "type": "String"
  },
  "proposer": {
    "data": "0xf47c189056ab295854e4752f3dc61e1800793d56e500a97efabd1e281ddbd1c1",
    "type": "String"
  },
  "accountId": {
    "data": "0xa31e62d6af4041f9fc992ec8d6cda68a6e74482b0c2d59204f9f8c4c64f87ca5",
    "type": "String"
  },
  "__typename": {
    "data": "Proposal",
    "type": "String"
  },
  "paramsHash": {
    "data": "0x5f0497643ffca224e98f82826ef3ba0d4ffd90358c3230a55e26c1923a564510",
    "type": "Bytes"
  },
  "prediction": {
    "data": "1",
    "type": "BigInt"
  },
  "proposalId": {
    "data": "0x2c766d6d269d8cef520aeaf4e78bed2db4cb59ed07330e203dcafe50f4a637f1",
    "type": "String"
  },
  "reputation": {
    "data": "0",
    "type": "BigInt"
  },
  "voteOption": {
    "data": "1",
    "type": "BigInt"
  },
  "stakeAmount": {
    "data": "50000000000000000000",
    "type": "BigInt"
  },
  "numOfChoices": {
    "data": "2",
    "type": "BigInt"
  },
  "executionTime": {
    "data": "1542257912",
    "type": "BigInt"
  },
  "submittedTime": {
    "data": "1542257064",
    "type": "BigInt"
  }
}

You'll notice that this Proposal entity also contains fields that belong to the Vote & Stake entities. Further, if you compare this data to the raw event data you'll see that the proposer is incorrect.

Explore this graphql API further yourself on my staging server

These mappings have been synced onto fresh databases on two different servers (the other one is here) and the results on both is the same.

This may be unrelated but at the same point that I started noticing this issue, I also started seeing errors fill my graphiql UIs console that repeat the following many times.

Name "__typename" must not begin with "__", which is reserved by GraphQL introspection.

I'm using graph-ts and graph-cli v0.4.1 and running docker image graphprotocol/graph-node:latest (I won't know the exact version associated w this particular "latest" image until issue #591 is resolved)

Thank you for your time.

[davekay100]

It also appears that the Redemption fields are being added here too. the type field is present in the proposal entity. and type is a redemption field

[davekay100]

my hunch is that it has something to do with the fact some of the relational entities dont have the ID! fields set. But I am not sure. Whenever I build subgraphs I give every schema a field with id: ID!, and I haven't come across this problem you are having/

We are looking into it deeper, but it might be worth it to try this and see what happens, while we try to investigate whats going on with the DB!

[leoyvens]

@bohendo Did you get a chance to try to reproduce this after 0.5?

[bohendo]

@leodasvacas I gave it a shot but hit some problems and haven't had the bandwidth to dig into it too deeply yet.

I did set id: ID! on each entity in the schema as @davekaj suggested and I also upgraded to 0.5 which seemed to require a slight change of syntax. I was getting an error that new Entity() expected an argument and couldn't find any documentation so guessed that the argument it wanted was an id. I added an id arg while creating new entities (<- this is the source code that I most recently tried to deploy) and that fixed the build-time errors but then at run-time an old bug resurfaced:

alchemy_graph.1.uxmpj9887hz3@staging    |   Dec 17 04:01:05.452 ERRO Subgraph instance
failed to run: Failed to process event: Failed to handle Ethereum event with handler
"handleMint": Trap: Trap { kind: Host(HostExportError("Value of Account attribute \'id\'
conflicts with ID passed to `store.set()`:
0xf04c14d74c9b6b2d6128783550aef6c288d335751b089581e0468b81bdc9b0c6 !=
0x371e817fa6454c98d60aff4278cbda753180d9ecd33d10707f01de0eea8053b7")) }, id:
QmcYPchWpmgCMcYqm4KzPFvnXAQ8ZY7TWXL6Pomjh11efZ

This bug was discussed in the Discord chat on Nov 19th, 2018 (wish there was a way to link to that conversation) & @Jannis was hugely helpful in getting it fixed (in that same debugging session I also noticed a problem w the entity data for the first time so these two problems may be related). I was manually setting entity.id = uniqueId but the entity's id is set automatically when calling store.set so I was able to remove these explicit assignments and the conflicting id error shown above disappeared. Now that I've upgraded to the new syntax, this error has reemerged. Can't tell whether it's a bug in my subgraph or the underlying env.

I can't really check whether this parent issue is solved until my graph syncs & it won't sync properly until this conflicting ID error is solved.

[leoyvens]

@bohendo Thanks for trying the new version and for the detailed report of the new issue, don't know yet if it's related or not. I'll try to build a minimal reproduction case to better investigate. Also we noticed that we didn't get our attempted fix quite right, so it's unlikely that the original issue is fixed. Hopefully I'll be able to reproduce that as well.