After discussing it with @kamil and @tomek we concluded that changes necessary to be done in this diff include:

1. Sequentially awaiting db ops processing before notifs processing.
2. Put MessageData directly in DBOpsEntry.

PR: https://github.com/marcinwasowicz/localForage/pull/1

In D12941#365887, @inka wrote:

Rename file - I am not sure how to name this, but this seems better

In D12951#366176, @tomek wrote:

About option 1 vs option 2: I think it is much worse if we have a false-negative token invalidation than a false-positive.
False-positive means that we think that a token is invalid when it is valid. In this case, we would ask a client to send a new token. If we have a good validation of notifications on Tunnelbroker, then it is unlikely to cause serious issues.
False-negative means that we think that a token is valid when it isn't. We won't be able to send any notif and don't have a way of recovering from it.

About option 1 vs option 2: I think it is much worse if we have a false-negative token invalidation than a false-positive.
False-positive means that we think that a token is invalid when it is valid. In this case, we would ask a client to send a new token. If we have a good validation of notifications on Tunnelbroker, then it is unlikely to cause serious issues.
False-negative means that we think that a token is valid when it isn't. We won't be able to send any notif and don't have a way of recovering from it.

Yeah, I think that's the plan

update to option 1

remove client code

rebase

In D12939#366010, @bartek wrote:

In what situations are we going to keep using the old SetDeviceTokenWithoutPlatform?

I am going to remove client code from this diff before landing (we first need to deploy TB) and then I'll create a second diff with only client changes.

address review

Not sure if @ashoat's comment demands changes to this diff, please make sure to address it

This is great!

Can't we handle this in useProcessDMOperation just like canBeProcessed?

Should we set the unread status?

In D12926#366075, @ashoat wrote:

I think we'll need to update the two handler components here to look at the newly-returned reservedUserIdentities property, but my impression is that this will be handled by @inka in a later diff

Rename to reservedUserIdentifiers

Rename to reserved_user_identifiers

What about +community?: ?string, field?

Rename to reserved_user_identifiers

Rename to reserved_user_identifiers

Makes sense. I think we'll need to update the two handler components here to look at the newly-returned reservedUserIdentities property, but my impression is that this will be handled by @inka in a later diff

Haven't reviewed the Rust but the changes seem minimal / safe

Looks legit

I had previously suggested implemented a solution to this based on a tcomb validator. We'll need to specify IDs that have to be checked for collision again certain SQLite tables, and I was planning on using a tcomb validator approach for that. It seems like checking IDs for existence in certain SQLite tables is a very similar problem, and ought to be solved in a similar way.

Planning to change .env to secrets.json approach

Change the API

In D12928#366013, @bartek wrote:

General question:
What's the advantage of sops-encrypting new .env files instead of reusing our sops_file resource for secrets.json, having webapp-specific config inside it, and then doing

webapp_environment_vars = merge(local.secrets.webapp_secrets,  { ... })

?

I'm not saying your approach is bad, I just want to understand the motivation

General question:
What's the advantage of sops-encrypting new .env files instead of reusing our sops_file resource for secrets.json, having webapp-specific config inside it, and then doing

webapp_environment_vars = merge(local.secrets.webapp_secrets,  { ... })

?

In what situations are we going to keep using the old SetDeviceTokenWithoutPlatform?

Update yarn.lock

Generally okay, personally I'd organize it a bit differently but that doesn't matter

add missing errors

Forgot to add missing error - sorry for that