Do we need to use this function given we're just doing a read? I think the function call is only necessary if we need to lock for writes.

We need since if someone if performing a write operation we need to wait with reading until they are done.

Why do we need to wait for the write to complete? Is there something bad that can happen in this scenario, that wouldn't happen in a scenario where createOlmSession got called right before an update? I assume we (and Olm) need to be resistant to the second scenario, so my assumption is that the first scenario will work as well

We need to answer some questions here:

1. Does creating a new session using an account changes internal state of an account - does it change its pickled content we keep in the db. If the answer is no, then we can do unblocking read and skip updating database.
2. If the answer to the first question is yes, then we need to answer another question. Is olm able to recover if we skip persisting updated olm account in the db after creating a session. If the answer to this question is yes, we can do unblocking read and skip updating database.
3. If the answer to the second question is no, then we have to ensure the sequence read -> create session-> update db executes atomically. Imagine a case when we read olm account with prekey older than 30 days and use it the to create olm session. When we are busy creating olm session the cron generates new prekey and persists to the db an account with new prekey. Once we are done creating new olm session we persist to the db an account with the old prekey and we wait another 24 hours before we create new one. This is just an example but I hope it presents my point well.

cc @anunay

1. I think no. It may be worth confirming this... perhaps the easiest way would be to modify @anunay's unit tests in D7670 to create a new session, and then to check to see if the contents of the pickled account have changed.
2. N/A
3. I am not sure I follow your concern about this scenario. It should be okay for the native/web client to create an outgoing session using the keyserver's old prekey, since the keyserver will keep the old prekey for 24 hours. I'm not sure what you mean when you say "Once we are done creating new olm session we persist to the db an account with the old prekey"... the olm-session-creator.js code you introduce here does not seem to save accounts (just sessions). As for the cronjob, it will save the new account, but the old prekey will still be there, so it should not cause any problems.

the olm-session-creator.js code you introduce here does not seem to save accounts (just sessions)

It does. fetchCallUpdate saves account after calling lambda.

Scenario with the prekey was just an example. My point is that if creating new olm session alters pickled content of an account then we must ensure atomicity in sequence read->create session -> write. Otherwise changes we made when creating session might be lost when something else writes. If there are no changes when creating a session, or loosing those changes can be handled by olm, then we can bypass fetchCallUpdate function and just read relevant information from the db. However if we can't loose those changes we need atomicity and fetchCallUpdate guarantees that.

the olm-session-creator.js code you introduce here does not seem to save accounts (just sessions)

It does. fetchCallUpdate saves account after calling lambda.

My whole point is that fetchCallUpdateOlmAccount does not need to be called. If you take my solution, this will not be a problem.

Scenario with the prekey was just an example. My point is that if creating new olm session alters pickled content of an account then we must ensure atomicity in sequence read->create session -> write. Otherwise changes we made when creating session might be lost when something else writes. If there are no changes when creating a session, or loosing those changes can be handled by olm, then we can bypass fetchCallUpdate function and just read relevant information from the db. However if we can't loose those changes we need atomicity and fetchCallUpdate guarantees that.

I agree with this. I am pretty sure that creating a new Olm session does not alter pickled content of the account. As suggested in my previous comment, you can confirm this by testing.

Confirmed by testing that session creation does not alter pickled content of olm account.