In D12776#361904, @ashoat wrote:

Would probably be a good idea to discuss this in my detail in our 1:1 tomorrow. One tradeoff neither of us has mentioned so far about using a single action for all business logic that generates DMOperations is that it might be debugging a little bit more painful.

Yes, definitelly.

Don't create messages from actions

Rebase

Rebase

Rebase

Rebase

Rebase

Hmm... to me, I think it would be much more simple to have the components generate a DMOp, and then to have a utility function that calls processDMOperation on it, and put the result in a Redux action. That way, we avoid having to support multiple different kinds of actions. What do you think?

Yeah, agree, it's simpler. It's similar to an updated solution I was thinking about. But there are some things we have to figure out:

1. As of D12780 processDMOperation returns rawMessageInfos and updateInfos. But we also need to generate OutboundP2PMessages (generateMessagesToPeers function from this diff) - we probably should do that as a part of processDMOperation.
2. We need to know the sending status of messages that aren't automatically retriable. We can have a function that takes OutboundP2PMessages and returns a promise that can be passed to dispatchActionPromise.
3. Manual retries need IDs of failed messages - that is something relevant only for local messages. But we will need to modify them in a way that allows storing the IDs.

Figured sharing these makes us sure we're on the same page.

Use boolean value

Rebase

Return boolean value

It might be a good idea to test both insert and update.

This diff looks confusing to me. We're introducing a new context PeerOlmSessionCreatorContext but it doesn't look like we're using it.

In D12776#361491, @ashoat wrote:

Can you provide some more context about this? I don't quite understand why it makes sense to start from an action... my initial thinking was that business logic would construct a DMOperation directly, rather than constructing an action that gets converted into a DMOperation

Rename

Fix indentation

Rename column

Nice!

It's great to see these bindings! At some point, we should delete NullableString and NullableInt.

This diff caused https://linear.app/comm/issue/ENG-8810/unable-to-login - we're reading from the new index but we didn't create records in it for existing users.

In D12673#358848, @marcin wrote:

I am afraid that there is a vulnerability in this diff. Basically it is possible that two createOlmSessionWithPeer promises will execute concurrently. This might lead to corrupted state. In order to mitigate that I think it is best expose this method as a context. The context would internally keep a map like [(userID, deviceID)] : Promise mapping from particular deviceID and userID to currently executing promise (if any).

Shouldn't the test plan be expanded?

Check the IDs in state sync specs

Squash

Extract a function

one try per startup

Why do we want to do this only once? Is there a downside to setting loginAttemptedRef.current to false after the login is done?

we're already auth'd with the authoritative keyserver

Why is it guaranteed?

In D12422#355471, @inka wrote:

"within" is not centered on web (vertically), can we fix this?