REQUEST_PLUS does not show documents under update

I have a set of documents that I keep updating their fields (via upsert).
While frequently query the documents, some of those updated documents are not retrieved.
That is even if i user REQUEST_PLUS.
Is there a time during upsert process that the document is not indexed?
will “mutateIn” help to solve it?

1 Like

@amit2 , Using REQUEST_PLUS scan consistency ensures the updates(mutations) that bucket received as of the time scan request is received by GSI indexer server are indexed. So, it is not expected that your updates are not indexed if REQUEST_PLUS is specified.
Few questions: How are you setting scan consistency and how are the documents being retrieved? (query UI or SDK?)

I use JS SDK:
const query = N1qlQuery.fromString(qs);
If you need to retrieve your own updates you may want to explore at_plus

Also check all the nodes system times in cluster are synchronizeed.

1 Like

@vsr1 to my understanding, consistency wise, REQUEST_PLUS is just as strong as AT_PLUSE

REQUEST_PLUS: The indexer becomes consistent with bucket mutations upto the time when scan request reaches indexer server.
AT_PLUS: The user specifies a timestamp vector which is passed on to indexer server so that it can become consistent upto that point before serving scans.
AT_PLUS gives you better control in doing RYOW (Read Your Own Writes). I suggest try out AT_PLUS consistency option.

I guess i’m missing something. From this description REQUEST_PLUS is consistently stronger. the The timestamp used for consistency in REQUEST_PLUS is always later in than in AT_PLUS.

Regardlress, AT_PLUS can be a problem as i use multiple writers…

@amit2, your understanding is correct. request_plus is a superset of at_plus and provides stronger consistency. We haven’t seen any issue of missing results with request_plus. While serving a request_plus scan, indexer gets the list of latest mutation sequence numbers from data service and processes the scan only when the indexing has reached till that point. If your document update has been received at the server, it shouldn’t be a problem. If you are using async SDK apis and multiple writers, it could be possible that a mutation has not yet been received at the server before the scan gets issued.

1 Like

That makes sense. Thanks.

Can you elaborate more on that topic? How can async api results in out of consistency?
If I Update an existing document via upsert, is there a point in time that the document does not exists in db or index?

If you are using async upsert, you need to make sure to observe that the update has reached the server before issuing a query. Also, if multiple writers are doing upsert in different threads, the query needs to be issued once all of these have been successful, if the expectations is to receive all the updated results via request_plus.