I am not sure if that is what you were thinking about but an attempt to use it in the following way:

tShape({
   type: t.String(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE),
   initialNotificationsEncryptedMessage: t.String,
 }),

results in flow error:

Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ src/socket/session-utils.js:136:13

Cannot call t.String because a call signature declaring the expected parameter / return type is missing in
TIrreducible [1]. [prop-missing]

     src/socket/session-utils.js
     133│     signedIdentityKeysBlob: signedIdentityKeysBlobValidator,
     134│   }),
     135│   tShape({
     136│     type: t.String(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE),
     137│     initialNotificationsEncryptedMessage: t.String,
     138│   }),
     139│ ]);

     ../lib/flow-typed/npm/tcomb_v3.x.x.js
 [1] 110│     +String: TIrreducible<string>,
Found 1 error

The keyserver has to olm accounts: one for notifications and the other for communication with identity service. createOlmSession can be used to create session for both of this accounts. This argument informs which olm account we will use to create olm session. In this particular case we will use olm accounts for e2e notifications.

I think it si for three reasones:

1. It has already been used for other requests and proved to work.
2. If it fails, the keyserver will re-attempt to retrieve this data from the client.
3. If this fails due to some permanent db failure we will be informed by prepareEncryptedIOSNotifications function that we are constantly missing olm session for a client that has code version high enough to handle notification encryption.
4. The client code in this stack is implemented in a way that it is aware of a case when notifications are delivered unencrypted. When this issue: https://linear.app/comm/issue/ENG-2670/c-equivalent-of-dev-flag#comment-45f70230 is resolved staff members will be informed that their notifications are delivered unencrypted.

Until the linear issue mentioned above is not resolved we don't really have a proper way to handle such failure on the client.