Worth adding to the Summary or Test Plan that this includes all RPC (all usages of getRustAPI) other than unath RPCs.

rebase before landing

rebase before landing

add missing check

address review

fix comment typo

address review

In D13970#389656, @will wrote:

Testing that adding WEB_PUSH_ERROR and APNS_ERROR error types to an error log will trigger an alarm + email notif has already been tested. I don't think this needs further testing.

The best way of testing this would be to ensure that failing to sending APNs error or Web Push notif logs the error. Cloudwatch alarms will take care of the rest

Doing this locally and ensuring you can find the error logs should be sufficient imo

Please check https://phab.comm.dev/D13951#389437 before landing

In D13951#389437, @ashoat wrote:

Just wondering, what do you think of this style?

const { userID, cookieID, sessionID } = viewer;
const data = { userID, cookieID, sessionID };
console.log(
  'Sending INITIAL_NOTIFICATIONS_ENCRYPTED_MESSAGE ' +
    JSON.stringify(data),
);

Could work both here and in D13952.

There is some discussion about user-facing language so probably @ashoat should do the final review

In D13939#389428, @ashoat wrote:

I guess a way to reframe what you're saying about useUsersSupportThickThreads is that userHasDeviceList doesn't match findUserIdentities in the case of an empty device list. We end up returning the correct answer anyways, since we check findUserIdentities as a fallback. But it would be better if we were able to get the right answer without having to query the identity service.

In D13939#389043, @ashoat wrote:

Hmmm... I know I initially proposed doing both D13938 and this, but after reading D13938 I wonder if we need this additional mechanism.

@kamil, do you know if it's possible for the user to see a thick thread in the UI if one of the members doesn't pass the userHasDeviceList check? Specifically in this case, I'm wondering about a PERSONAL thread, like in @tomek's original report in ENG-9509. It seems to me that the thread creation message would have had to come in from an established Olm session, so I would expect that userHasDeviceList would always be true, and the check in D13938 would suffice.