We can't safely separate updating and storing an Olm session due to the potential for a race between two calls that are both trying to update the Olm session. For that reason we have fetchCallUpdateOlmAccount and encryptAndUpdateOlmSession, which use MariaDB transactions to protect against the race conditions.

We don't need that sort of approach for persisting a brand new Olm session. But it's concerning to see you export storeOlmSession here... it seems like it has the potential for misuse.

Maybe we can rename it to storeFreshOlmSession?

Separately, wonder if "persist" makes more sense than "store". I don't feel strongly here... curious for @marcin's perspective.

persistOlmSession sounds best for me as a name for this method.

The issue that I see with this diff is that createOlmSession persists changes made to olm account in the database while changes done due to the session creation are not persisted immediately.. Our database has an entry associated with olm account that indicates that a session was created but there is no entry with the actual session. This means that our database is in incorrect state for a while until persistOlmSession is called. On the other hand I am not sure if it creates a foundation for some serious issues. Actually I can't think of any bad scenario that could happen here. As far as I am concerned creating a session indeed removes one time key from an account. So theoretically if we create a session but the keyserver crashed before we persist it in the database we might not be able to try to create it again with the same initialEncryptedMessage since necessary one time key was permanently removed from an account. If the scenario I described above is a serious concern then here is what I would do:

1. createOlmSession doesn't update database but returns olm session, old olm account and updated olm account in memory.
2. persistOlmAccount takes pickled old olm account, pickled updated olm account and pickled olm session as arguments, then fetches pickled olm account from the database and if it matches the old pickled olm account passed as an argument then we update everything in the database at once.