Collection locks are misbehaving when querying

[epii-1]

@keski I found a strange bug while trying to implement edge deletions. I run the following mutations (in different transactions):

create object1
create object2
# Query nr1 of object1
create edgeFromObject1ToObject2
# Query nr2 of object1
delete edgeFromObject1ToObject2
# Query nr3 of object1

This works just fine while ran like this and queried once at any location. However, if I start querying at multiple locations during these mutations strange things starts to happen: If I query object1 at location 1, neither query nr2 nor query nr3 will contain the edge create in the create edge operation. If I skip query nr1 while still doing query 2 and 3, both query nr3 and nr2 will contain the edge. If I skip both 1 and 2, 3 will not contain the edge.

So to me it looks like the query result is decided the first time an object/collection is queried and is there after static. I suspect that query operations does not release their read locks and therefor prevents the later mutations. At the same time I can not see that we ever explicitly get any locks for the get operations.

See the edge_delete branch for testing. I also have an example (using the spirit schema) I can dm you to test it out. But you should be able to achieve similar results on the current dev. build by just skipping the delete edge operation and the third query.

[epii-1]

After doing som testing this does not appear to be a lock issue. But rather either a client- or server side caching issue. The get-functions are not called when an object are queried the second time. I hope this is just a client-test issue.

[epii-1]

It is a client side cache problem. Apollos client cache does not detect updates for connected objects/edges automatically (which might turn into another problem). await client.clearStore() in between queries works just fine.