Change Details

I move the call to the identity service outside of the `fetchOlmUpdateAccount` block, to avoid a scenario where the identity service is uploaded keys that don't get persisted in the keyserver MariaDB. See [here](https://linear.app/comm/issue/ENG-6908/olm-session-creation-failure#comment-ead4250a) for a description of the issue this resolves (scenario 4). Given that both this and scenario 1 have to do with `fetchUpdateOlmAccount`, I wonder if we should consider what I suggested in my comment about scenario 1: > Perhaps the best solution to this would be to rearchitect `fetchUpdateOlmAccount` to use locking, so that it could support multiple simultaneous calls. While working on this diff, I considered a potential risk that the client might end up with keys that don't get uploaded to identity. This situation where the client has more one-time keys than identity can be dangerous if the client ends up with more than 100 one-time keys, and starts pruning them. At that point, the keys pruned in the client might still be on identity. However, this scenario seems relatively unlikely with the current implementation of one-time key refresh in the keyserver, where we debounce the requests, and they are only initiated when the number of one-time keys drops below 5.

I move the call to the identity service outside of the `fetchOlmUpdateAccount` block, to avoid a scenario where the identity service is uploaded keys that don't get persisted in the keyserver MariaDB. See [here](https://linear.app/comm/issue/ENG-6908/olm-session-creation-failure#comment-ead4250a) for a description of the issue this resolves (scenario 4). While working on this diff, I considered a potential risk that the client might end up with keys that don't get uploaded to identity. This situation where the client has more one-time keys than identity can be dangerous if the client ends up with more than 100 one-time keys, and starts pruning them. At that point, the keys pruned in the client might still be on identity. However, this scenario seems relatively unlikely with the current implementation of one-time key refresh in the keyserver, where we debounce the requests, and they are only initiated when the number of one-time keys drops below 5.

I move the call to the identity service outside of the `fetchOlmUpdateAccount` block, to avoid a scenario where the identity service is uploaded keys that don't get persisted in the keyserver MariaDB. See [here](https://linear.app/comm/issue/ENG-6908/olm-session-creation-failure#comment-ead4250a) for a description of the issue this resolves (scenario 4). Given that both this and scenario 1 have to do with `fetchUpdateOlmAccount`, I wonder if we should consider what I suggested in my comment about scenario 1: > Perhaps the best solution to this would be to rearchitect `fetchUpdateOlmAccount` to use locking, so that it could support multiple simultaneous calls. While working on this diff, I considered a potential risk that the client might end up with keys that don't get uploaded to identity. This situation where the client has more one-time keys than identity can be dangerous if the client ends up with more than 100 one-time keys, and starts pruning them. At that point, the keys pruned in the client might still be on identity. However, this scenario seems relatively unlikely with the current implementation of one-time key refresh in the keyserver, where we debounce the requests, and they are only initiated when the number of one-time keys drops below 5.