Can anyone answer these questions regarding read/write concerns. I’ve read the documentation, but it’s so vast I struggle to find specific answers to what I don’t understand.
After issuing an unacknowledged write {w:0} do reads from the primary (or any other members) wait for the operation to finish?
After issuing a majority write to the primary, could a majority read from a secondary come from one of the members that has not received the update? or does it wait? or does the driver select a suitable member that has received the update?
These guarantees hold across all members of the MongoDB deployment. For example, if, in a causally consistent session, you issue a write with "majority" write concern followed by a read that reads from a secondary (i.e. read preference secondary) with "majority" read concern, the read operation will reflect the state of the database after the write operation.
I don’t know how the magic happens, but good enough for me.
Regardless of a write’s write concern, other clients using "local" or "available" read concern can see the result of a write operation before the write operation is acknowledged to the issuing client.
This example further clarifies the timeline, so it seems reads do not wait.
Looks like you found your own answers, and in fact those are correct - local (aka default) reads don’t wait for data to be acknowledged or replicated to read it, and the same goes for majority readConcern - it will read the latest majority committed data, but it will not necessarily be the same data that previous write operation waited for.