Page MenuHomePhabricator
Differential D9139

[feature-flags] Use default HTTP port for deployments
ClosedPublic
Actions

Authored by bartek on Sep 12 2023, 12:13 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 25, 4:47 PM
Unknown Object (File)
Sun, Mar 23, 9:02 AM
Unknown Object (File)
Sun, Mar 23, 9:02 AM
Unknown Object (File)
Sun, Mar 23, 9:02 AM
Unknown Object (File)
Sun, Mar 23, 9:02 AM
Unknown Object (File)
Sun, Mar 23, 9:02 AM
Unknown Object (File)
Sun, Mar 23, 2:19 AM
Unknown Object (File)
Sun, Mar 23, 12:50 AM
View All Files
Subscribers
ashoat

Details

Reviewers
michal
tomek
varun
• jon
Commits
rCOMM993b9cbd3d02: [feature-flags] Use default HTTP port for deployments
Summary

Deploy feature-flags service with new default HTTP port

NOTE: Applying the terraform changes requires rebuilding the docker image first! See the test plan.

Depends on D9138

Test Plan

On Staging:

  1. Build new docker image for feature-flags (latest tag)
  2. Apply terraform

Repeat on prod right before landing, with 0.1.1 docker tag

In case of problems, revert this and terraform apply again - this will revert deployment back to the existing v0.1

Diff Detail

Repository
rCOMM Comm
Branch
barthap/blob-docker
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

bartek created this revision.Sep 12 2023, 12:13 AM
bartek held this revision as a draft.
Herald added a reviewer: • jon. · View Herald TranscriptSep 12 2023, 12:13 AM
Herald added a subscriber: ashoat. · View Herald Transcript
bartek published this revision for review.Sep 12 2023, 12:22 AM
bartek mentioned this in D9138: [feature-flags] Standardize localstack and http config.
bartek edited the test plan for this revision. (Show Details)
Harbormaster completed remote builds in B22512: Diff 30949.Sep 12 2023, 12:29 AM
michal added a comment.Sep 12 2023, 12:34 AM

Should we also update the docker-compose.yml to use the new port?

About the applying terraform issue: maybe I'm misunderstanding something but couldn't we just bump the service version?

bartek planned changes to this revision.Sep 12 2023, 9:22 AM
bartek edited the test plan for this revision. (Show Details)Sep 12 2023, 11:09 PM
bartek updated this revision to Diff 31023.Sep 12 2023, 11:09 PM

Use separate tag for staging, bump prod version

Harbormaster completed remote builds in B22572: Diff 31023.Sep 12 2023, 11:27 PM
bartek added a child revision: D9176: [docker-compose] Match version tags with terraform.Sep 12 2023, 11:34 PM
michal accepted this revision.Sep 13 2023, 12:44 AM

Should we also update the docker-compose.yml to use the new port?

This revision is now accepted and ready to land.Sep 13 2023, 12:44 AM
bartek added a comment.Sep 13 2023, 12:46 AM
In D9139#269877, @michal wrote:

Should we also update the docker-compose.yml to use the new port?

yes, I forgot to change it 🙄

bartek updated this revision to Diff 31029.Sep 13 2023, 3:52 AM

Update port in docker-compose

Harbormaster completed remote builds in B22578: Diff 31029.Sep 13 2023, 4:10 AM
Closed by commit rCOMM993b9cbd3d02: [feature-flags] Use default HTTP port for deployments (authored by bartek). · Explain WhySep 13 2023, 4:26 AM
This revision was automatically updated to reflect the committed changes.
bartek added a commit: rCOMM993b9cbd3d02: [feature-flags] Use default HTTP port for deployments.

Revision Contents
Changeset List

PathSize
services/
2 lines
feature-flags/
3 lines
terraform/
remote/
6 lines

Diff 31023

View Options

services/docker-compose.yml

Show All 35 Lines
import { hash } from 'lib/utils/objects.js'; import { hash } from 'lib/utils/objects.js';
import { promiseAll } from 'lib/utils/promises.js'; import { promiseAll } from 'lib/utils/promises.js';
import { import {
tShape, tShape,
tPlatform, tPlatform,
tPlatformDetails, tPlatformDetails,
} from 'lib/utils/validation-utils.js'; } from 'lib/utils/validation-utils.js';
import { createOlmSession } from '../creators/olm-session-creator.js';
import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js'; import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js';
import createReport from '../creators/report-creator.js'; import createReport from '../creators/report-creator.js';
import { SQL } from '../database/database.js'; import { SQL } from '../database/database.js';
import { import {
fetchEntryInfos, fetchEntryInfos,
fetchEntryInfosByID, fetchEntryInfosByID,
fetchEntriesForSession, fetchEntriesForSession,
} from '../fetchers/entry-fetchers.js'; } from '../fetchers/entry-fetchers.js';
▲ Show 20 Lines • Show All 74 Lines • ▼ Show 20 Linesconst clientResponseInputValidator: TUnion<ClientResponse> = t.union([
}), }),
tShape({ tShape({
type: t.irreducible( type: t.irreducible(
'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB', 'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB',
x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB, x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB,
), ),
signedIdentityKeysBlob: signedIdentityKeysBlobValidator, signedIdentityKeysBlob: signedIdentityKeysBlobValidator,
}), }),
tShape({
type: t.irreducible(
'serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE',
tomekUnsubmitted
Not Done
Inline Actions

I know this approach was used earlier, but isn't it just tString(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE)?

tomek: I know this approach was used earlier, but isn't it just `tString(serverRequestTypes.
marcinAuthorUnsubmitted
Done
Inline Actions

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
marcin: I am not sure if that is what you were thinking about but an attempt to use it in the following…
x => x === serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE,
),
initialNotificationsEncryptedMessage: t.String,
}),
]); ]);
type StateCheckStatus = type StateCheckStatus =
| { status: 'state_validated' } | { status: 'state_validated' }
| { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> } | { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> }
| { status: 'state_check' }; | { status: 'state_check' };
type ProcessClientResponsesResult = { type ProcessClientResponsesResult = {
serverRequests: ServerServerRequest[], serverRequests: ServerServerRequest[],
▲ Show 20 Lines • Show All 83 Lines • ▼ Show 20 Lines ) {
setCookieSignedIdentityKeysBlob( setCookieSignedIdentityKeysBlob(
viewer.cookieID, viewer.cookieID,
signedIdentityKeysBlob, signedIdentityKeysBlob,
), ),
); );
} catch (e) { } catch (e) {
continue; continue;
} }
} else if (
clientResponse.type ===
serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE
) {
invariant(
clientResponse.initialNotificationsEncryptedMessage,
'initialNotificationsEncryptedMessage expected in client response',
);
tomekUnsubmitted
Not Done
Inline Actions

It would be better if it was verified using tComb validator

tomek: It would be better if it was verified using `tComb` validator
const { initialNotificationsEncryptedMessage } = clientResponse;
try {
await createOlmSession(
initialNotificationsEncryptedMessage,
'notifications',
tomekUnsubmitted
Not Done
Inline Actions

What is the meaning of this value?

tomek: What is the meaning of this value?
marcinAuthorUnsubmitted
Done
Inline Actions

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.

marcin: The keyserver has to olm accounts: one for notifications and the other for communication with…
viewer.cookieID,
);
} catch (e) {
continue;
}
tomekUnsubmitted
Not Done
Inline Actions

Is it safe to ignore the exception? Would the client ever know that something went wrong?

tomek: Is it safe to ignore the exception? Would the client ever know that something went wrong?
marcinAuthorUnsubmitted
Done
Inline Actions

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.

marcin: I think it si for three reasones: 1. It has already been used for other requests and proved to…
} }
} }
const activityUpdatePromise = (async () => { const activityUpdatePromise = (async () => {
if (activityUpdates.length === 0) { if (activityUpdates.length === 0) {
return undefined; return undefined;
} }
return await activityUpdater(viewer, { updates: activityUpdates }); return await activityUpdater(viewer, { updates: activityUpdates });
▲ Show 20 Lines • Show All 361 Lines • Show Last 20 Lines
View Options

services/feature-flags/Dockerfile

Show All 35 Lines
import { hash } from 'lib/utils/objects.js'; import { hash } from 'lib/utils/objects.js';
import { promiseAll } from 'lib/utils/promises.js'; import { promiseAll } from 'lib/utils/promises.js';
import { import {
tShape, tShape,
tPlatform, tPlatform,
tPlatformDetails, tPlatformDetails,
} from 'lib/utils/validation-utils.js'; } from 'lib/utils/validation-utils.js';
import { createOlmSession } from '../creators/olm-session-creator.js';
import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js'; import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js';
import createReport from '../creators/report-creator.js'; import createReport from '../creators/report-creator.js';
import { SQL } from '../database/database.js'; import { SQL } from '../database/database.js';
import { import {
fetchEntryInfos, fetchEntryInfos,
fetchEntryInfosByID, fetchEntryInfosByID,
fetchEntriesForSession, fetchEntriesForSession,
} from '../fetchers/entry-fetchers.js'; } from '../fetchers/entry-fetchers.js';
▲ Show 20 Lines • Show All 74 Lines • ▼ Show 20 Linesconst clientResponseInputValidator: TUnion<ClientResponse> = t.union([
}), }),
tShape({ tShape({
type: t.irreducible( type: t.irreducible(
'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB', 'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB',
x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB, x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB,
), ),
signedIdentityKeysBlob: signedIdentityKeysBlobValidator, signedIdentityKeysBlob: signedIdentityKeysBlobValidator,
}), }),
tShape({
type: t.irreducible(
'serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE',
tomekUnsubmitted
Not Done
Inline Actions

I know this approach was used earlier, but isn't it just tString(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE)?

tomek: I know this approach was used earlier, but isn't it just `tString(serverRequestTypes.
marcinAuthorUnsubmitted
Done
Inline Actions

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
marcin: I am not sure if that is what you were thinking about but an attempt to use it in the following…
x => x === serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE,
),
initialNotificationsEncryptedMessage: t.String,
}),
]); ]);
type StateCheckStatus = type StateCheckStatus =
| { status: 'state_validated' } | { status: 'state_validated' }
| { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> } | { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> }
| { status: 'state_check' }; | { status: 'state_check' };
type ProcessClientResponsesResult = { type ProcessClientResponsesResult = {
serverRequests: ServerServerRequest[], serverRequests: ServerServerRequest[],
▲ Show 20 Lines • Show All 83 Lines • ▼ Show 20 Lines ) {
setCookieSignedIdentityKeysBlob( setCookieSignedIdentityKeysBlob(
viewer.cookieID, viewer.cookieID,
signedIdentityKeysBlob, signedIdentityKeysBlob,
), ),
); );
} catch (e) { } catch (e) {
continue; continue;
} }
} else if (
clientResponse.type ===
serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE
) {
invariant(
clientResponse.initialNotificationsEncryptedMessage,
'initialNotificationsEncryptedMessage expected in client response',
);
tomekUnsubmitted
Not Done
Inline Actions

It would be better if it was verified using tComb validator

tomek: It would be better if it was verified using `tComb` validator
const { initialNotificationsEncryptedMessage } = clientResponse;
try {
await createOlmSession(
initialNotificationsEncryptedMessage,
'notifications',
tomekUnsubmitted
Not Done
Inline Actions

What is the meaning of this value?

tomek: What is the meaning of this value?
marcinAuthorUnsubmitted
Done
Inline Actions

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.

marcin: The keyserver has to olm accounts: one for notifications and the other for communication with…
viewer.cookieID,
);
} catch (e) {
continue;
}
tomekUnsubmitted
Not Done
Inline Actions

Is it safe to ignore the exception? Would the client ever know that something went wrong?

tomek: Is it safe to ignore the exception? Would the client ever know that something went wrong?
marcinAuthorUnsubmitted
Done
Inline Actions

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.

marcin: I think it si for three reasones: 1. It has already been used for other requests and proved to…
} }
} }
const activityUpdatePromise = (async () => { const activityUpdatePromise = (async () => {
if (activityUpdates.length === 0) { if (activityUpdates.length === 0) {
return undefined; return undefined;
} }
return await activityUpdater(viewer, { updates: activityUpdates }); return await activityUpdater(viewer, { updates: activityUpdates });
▲ Show 20 Lines • Show All 361 Lines • Show Last 20 Lines
View Options

services/terraform/remote/service_feature_flags.tf

Show All 35 Lines
import { hash } from 'lib/utils/objects.js'; import { hash } from 'lib/utils/objects.js';
import { promiseAll } from 'lib/utils/promises.js'; import { promiseAll } from 'lib/utils/promises.js';
import { import {
tShape, tShape,
tPlatform, tPlatform,
tPlatformDetails, tPlatformDetails,
} from 'lib/utils/validation-utils.js'; } from 'lib/utils/validation-utils.js';
import { createOlmSession } from '../creators/olm-session-creator.js';
import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js'; import { saveOneTimeKeys } from '../creators/one-time-keys-creator.js';
import createReport from '../creators/report-creator.js'; import createReport from '../creators/report-creator.js';
import { SQL } from '../database/database.js'; import { SQL } from '../database/database.js';
import { import {
fetchEntryInfos, fetchEntryInfos,
fetchEntryInfosByID, fetchEntryInfosByID,
fetchEntriesForSession, fetchEntriesForSession,
} from '../fetchers/entry-fetchers.js'; } from '../fetchers/entry-fetchers.js';
▲ Show 20 Lines • Show All 74 Lines • ▼ Show 20 Linesconst clientResponseInputValidator: TUnion<ClientResponse> = t.union([
}), }),
tShape({ tShape({
type: t.irreducible( type: t.irreducible(
'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB', 'serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB',
x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB, x => x === serverRequestTypes.SIGNED_IDENTITY_KEYS_BLOB,
), ),
signedIdentityKeysBlob: signedIdentityKeysBlobValidator, signedIdentityKeysBlob: signedIdentityKeysBlobValidator,
}), }),
tShape({
type: t.irreducible(
'serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE',
tomekUnsubmitted
Not Done
Inline Actions

I know this approach was used earlier, but isn't it just tString(serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE)?

tomek: I know this approach was used earlier, but isn't it just `tString(serverRequestTypes.
marcinAuthorUnsubmitted
Done
Inline Actions

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
marcin: I am not sure if that is what you were thinking about but an attempt to use it in the following…
x => x === serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE,
),
initialNotificationsEncryptedMessage: t.String,
}),
]); ]);
type StateCheckStatus = type StateCheckStatus =
| { status: 'state_validated' } | { status: 'state_validated' }
| { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> } | { status: 'state_invalid', invalidKeys: $ReadOnlyArray<string> }
| { status: 'state_check' }; | { status: 'state_check' };
type ProcessClientResponsesResult = { type ProcessClientResponsesResult = {
serverRequests: ServerServerRequest[], serverRequests: ServerServerRequest[],
▲ Show 20 Lines • Show All 83 Lines • ▼ Show 20 Lines ) {
setCookieSignedIdentityKeysBlob( setCookieSignedIdentityKeysBlob(
viewer.cookieID, viewer.cookieID,
signedIdentityKeysBlob, signedIdentityKeysBlob,
), ),
); );
} catch (e) { } catch (e) {
continue; continue;
} }
} else if (
clientResponse.type ===
serverRequestTypes.INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE
) {
invariant(
clientResponse.initialNotificationsEncryptedMessage,
'initialNotificationsEncryptedMessage expected in client response',
);
tomekUnsubmitted
Not Done
Inline Actions

It would be better if it was verified using tComb validator

tomek: It would be better if it was verified using `tComb` validator
const { initialNotificationsEncryptedMessage } = clientResponse;
try {
await createOlmSession(
initialNotificationsEncryptedMessage,
'notifications',
tomekUnsubmitted
Not Done
Inline Actions

What is the meaning of this value?

tomek: What is the meaning of this value?
marcinAuthorUnsubmitted
Done
Inline Actions

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.

marcin: The keyserver has to olm accounts: one for notifications and the other for communication with…
viewer.cookieID,
);
} catch (e) {
continue;
}
tomekUnsubmitted
Not Done
Inline Actions

Is it safe to ignore the exception? Would the client ever know that something went wrong?

tomek: Is it safe to ignore the exception? Would the client ever know that something went wrong?
marcinAuthorUnsubmitted
Done
Inline Actions

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.

marcin: I think it si for three reasones: 1. It has already been used for other requests and proved to…
} }
} }
const activityUpdatePromise = (async () => { const activityUpdatePromise = (async () => {
if (activityUpdates.length === 0) { if (activityUpdates.length === 0) {
return undefined; return undefined;
} }
return await activityUpdater(viewer, { updates: activityUpdates }); return await activityUpdater(viewer, { updates: activityUpdates });
▲ Show 20 Lines • Show All 361 Lines • Show Last 20 Lines