Removed entity is blocking creating another entity with the same id

[mihoward21]

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

What is the current behavior? I have two entity types with a shared interface, Split and User. When I go to create a new Split entity, I check to see if a User entity exists with the same id, and if yes I remove it first. I then create the split entity with that id. However, I am getting the following error:

Subgraph writer failed, error: tried to set entity of type 'Split' with ID "0xf8843981e7846945960f53243ca2fd42a579f719" but an entity of type 'User', which has an interface in common with 'Split', exists with the same ID

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. The error is occurring on this subgraph: https://thegraph.com/hosted-service/subgraph/0xsplits/splits-subgraph-kovan?version=pending

You can view the code here: https://github.com/0xSplits/splits-subgraph/blob/master/src/ethereum.mapping.ts#L99

A condensed version of it looks like:

export function handleCreateSplitCall(call: CreateSplitCall): void {
  let splitId = call.outputs.split.toHexString();

  let splitUserId = User.load(splitId);
  if (splitUserId) store.remove("User", splitId)
  
  let split = new Split(splitId);
  split.save();

What is the expected behavior? I would expect the split to be successfully created since the user entity with the same id was removed before the split was saved.

[azf20]

Thanks @mihoward21 - @lutter do you know if this is just an ordering issue?

[lutter]

It's a limitation in how we deal with ids for interfaces: we insist that once an id has been used, it's only ever used for the type it was initially used with (like User) in the example. I am not entirely sure about the background of that decision (@leoyvens might remember)

We could change it so that at any given block height the id must be unique across implementers of an interface, so that at block 10 the id 0x1 gives you a User, and at block 11 it gives you a Split. The example in this issue shows that there'll be some ordering concerns that must be taken into account so that the removal of the User happens before we check for id uniqueness.

[lutter]

@mihoward21 how important is it that you have a User and a Split with the same id? You could work around this issue by using different ids, and having an additional realID attribute; is that's part of the interface, you can query for that and get the right kind of entity back. Not super efficient, but would work.

[mihoward21]

@lutter yes I think that change could work for us. We will need to be a bit careful rolling out a change like that since it'll break current usage of our subgraph, might need to just create a new one.

If you all do think this an update you'll make at some point in the future to handle this case, that would be great. This issue isn't pressing for us. It's just an edge case caught in testing (it technically could happen at any time on mainnet, but it is a pretty rare situation for our data to get into, and as you pointed out we have a workaround if necessary).

[leoyvens]

The original design of the interface uniqueness check predates the relational schema, we'd need to revisit it to catch these edge cases which are now possible.

[github-actions[bot]]

Looks like this issue has been open for 6 months with no activity. Is it still relevant? If not, please remember to close it.

[leoyvens]

Still relevant.