Synchronous API insert and fetch

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [x] Performance issue
  • [ ] Documentation issue or request

Current behavior

When we insert a record via the API and then fetch it immediately after the records does not always exist. The second attempt to get the record always finds it though.

Expected behavior

We would expect a way request atomicity of the operations so when they are run in sequence and the first one returns the response it is understood that the record has been created and distributed to all data shards (or whatever the system has)

Minimal reproduction of the problem

Create and fetch a record with a script, run the script a hundred times.


Cloud -
App Name: currently crn-1949 but could be any app really.

  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x] Cloud version

Version: [VERSION]


  • [ ] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge


It is kind of by design because the reads are done using the secondary database members. What you experience is the replication lag.

I guess I can change the write concern, but I am not sure which implications it has on performance.


Hello Sebastian,

Thanks for sending the docs. I think it would be good to at least have an option of an acknowledgement that the change has been propagated to all replicas (not sure if the ‘majority’ setting would suffice). Do you think this is something you could add at some point soon?

Yes, this can be fixed.

If you use the X-Unpublished=1 flag, the reads will be done from the primary.

1 Like

thanks, thats exactly what i needed. cheers

1 Like