Instance not found even though instance exists and unique rule being ignored

Help
, ,
1

Data:

{
  "ref": Ref(Collection("eventInvitations"), "306981091611247115"),
  "ts": 1629018832705000,
  "data": {
    "eventId": "304363317135147532",
    "userId": "301269945372639745",
    "inviterId": "295664230831489541",
    "createdAt": "2021-08-15T09:13:52.474854Z",
    "updatedAt": "2021-08-15T09:13:52.474854Z"
  }
},
{
  "ref": Ref(Collection("eventInvitations"), "306981098447962635"),
  "ts": 1629018839220000,
  "data": {
    "eventId": "304363317135147532",
    "userId": "295664821370618375",
    "inviterId": "295664230831489541",
    "createdAt": "2021-08-15T09:13:59.044803Z",
    "updatedAt": "2021-08-15T09:13:59.044803Z"
  }
}

index:

CreateIndex({
  name: 'eventInvitationByUserEvent',
  source: Collection('eventInvitations'),
  terms: [
    { field: ['data', 'userId'] },
    { field: ['data', 'eventId'] }
  ],
  unique: true
})

query:

Exists(
  Match(
    Index("eventInvitationByUserEvent"),
    "295664821370618375",
    "304363317135147532"
  )
);

Expected: Should have returned true because the record exists, but it returned false saying the record does not exist.

{
  "ref": Ref(Collection("invitations"), "306981098447962635"),
  "ts": 1629018839220000,
  "data": {
    "eventId": "304363317135147532",
    "userId": "295664821370618375",
    "inviterId": "295664230831489541",
    "createdAt": "2021-08-15T09:13:59.044803Z",
    "updatedAt": "2021-08-15T09:13:59.044803Z"
  }
}

Using get:

Get(
  Match(
    Index("eventInvitationByUserEvent"),
    "295664821370618375",
    "304363317135147532"
  )
);

Throws:

Error: [
  {
    "position": [],
    "code": "instance not found",
    "description": "Set not found."
  }
]

BUT IT SHOULD NOT THROW BECAUSE THE RECORD EXISTS

{
  "ref": Ref(Collection("invitations"), "306981098447962635"),
  "ts": 1629018839220000,
  "data": {
    "eventId": "304363317135147532",
    "userId": "295664821370618375",
    "inviterId": "295664230831489541",
    "createdAt": "2021-08-15T09:13:59.044803Z",
    "updatedAt": "2021-08-15T09:13:59.044803Z"
  }
}

This doesn’t happen before but it seems it does now, I don’t know what’s up with this but seems reliability is down, hard for me to trust faunadb at this rate.

EDIT 1:

I also recently downgraded to FREE as I continue to develop the app, I don’t know if that has any impact on this.

EDIT 2:

Duplicates have also started appearing:

{
  "ref": Ref(Collection("eventInvitations"), "306982606624260678"),
  "ts": 1629020277530000,
  "data": {
    "eventId": "304363317135147532",
    "userId": "295664821370618375",
    "inviterId": "295664230831489541",
    "createdAt": "2021-08-15T09:37:57.278517Z",
    "updatedAt": "2021-08-15T09:37:57.278517Z"
  }
},
{
  "ref": Ref(Collection("eventInvitations"), "306983062861775371"),
  "ts": 1629020712774000,
  "data": {
    "eventId": "304363317135147532",
    "userId": "295664821370618375",
    "inviterId": "295664230831489541",
    "createdAt": "2021-08-15T09:45:11.422421Z",
    "updatedAt": "2021-08-15T09:45:11.422421Z"
  }
}

Notice same eventId and userId but it was declared as unique.

2

And now suddenly these queries work, seriously, what gives?

Exists(
  Match(
    Index("eventInvitationByUserEvent"),
    "295664821370618375",
    "304363317135147532"
  )
); // now returns true

Get(
  Match(
    Index("eventInvitationByUserEvent"),
    "295664821370618375",
    "304363317135147532"
  )
); // now returns the correct data
3

Hi @aprilmintacpineda

First I want to make sure it is clear that there are no additional constraints on using Fauna on the Free tier, other than the capacity limits and available features stated on the pricing page. There is no rate limiting or priority queueing of requests, for example, which would impact your usage.

Index issues

Were the example entries, which are not showing up in the index, created before or after the index? Can you share the timestamp on the index as well?

1 Like
5

Thanks for the clarification.

The documents were created AFTER the index was created. What impact would it have if the documents were created BEFORE the index? which I imagine would be a common thing to happen.

6

Hi @aprilmintacpineda . The short answer is that there can be a delay between creating an Index (and active is set to true) and the index being recognized to be written. We have an update ready for release that will ensure that there is never such a delay.

long answer

Fauna implements a cache of your schema in order to keep requests performant. Each replica node has it’s own cache. There can be a slight delay between creating your Index and all of the replica nodes’ caches being updated. Additionally, some of the nodes may be updated sooner, including the one that created the Index.

What this means is that, depending on how your requests are routed, some requests may go to nodes that are not yet aware of your new Index. Therefore an entry would not be written to the new Index.

Also note that if the Index is not being written to, it cannot enforce uniqueness constraints. This is why you were able to create two documents with matching terms.

The index build process will ensure that all existing data is included in the Index. The issue here is that some requests may go to nodes that don’t recognize the index exists yet. If the index finishes building (even with the existing data) quickly, there can still be a slight delay for future requests to write to the index.

Transactional schema cache coming soon

I already said that we have an update ready for release that will ensure that there is never such a delay. The update will ensure that once an Index is created (and active!) it will be immediately available to all future requests.

We will provide an update when it is deployed. It just needs to finish going through the QA process.

In the meantime

The issue is intermittent due to a variety of factors. If you are having this problem, we recommend:

  • Deleting the offending Index
  • Recreating the Index
  • Wait at least 5 minutes to add any Documents to the source Collection(s).
1 Like
7

The index build process will ensure that all existing data is included in the Index. The issue here is that some requests may go to nodes that don’t recognize the index exists yet. If the index finishes building (even with the existing data) quickly, there can still be a slight delay for future requests to write to the index.

This was my theory actually, the get request I sent probably went to a node where the index is still being created so it recognized the index (because if it doesn’t it actually throws a different error when you try to use an index that doesn’t exist) but the data is not yet up, but that’s kind of weird considering that my collection has less than 5 records in them, I would think it won’t take that long for the propagation to complete.

Transactional schema cache coming soon

I already said that we have an update ready for release that will ensure that there is never such a delay. The update will ensure that once an Index is created (and active!) it will be immediately available to all future requests.

We will provide an update when it is deployed. It just needs to finish going through the QA process.

Thanks for this!

8

Hi @aprilmintacpineda and other readers! Closing the loop on this one :tada:

The Transactional Schema Cache was deployed a couple of weeks ago and it’s been running smoothly. You should not see this type of issue again.

1 Like
9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.