EG

I don't think it makes sense to block @atul's work here on transforming that to the new Reanimated API. We'll probably need to have the Reanimated conversion be a monthly goal for someone...

In D9166#269944, @ashoat wrote:

I agree that it would be good to migrate away from the Reanimated 1 API... given it's deprecated in Reanimated 3, we'll eventually need to migrate there anyways. Looking at animateTowards though, it seems fairly complicated... I don't think it makes sense to block @atul's work here on transforming that to the new Reanimated API. We'll probably need to have the Reanimated conversion be a monthly goal for someone...

In D9165#270046, @michal wrote:

Would it make sense to add apply_immediately (at least for staging)? If I understand the documentation correctly, currently if we make changes to the user (or add broker configuration) we would have to reboot rabbitmq manually?

D8751 has been landed now, so it should be easier to dedup :)

Would it make sense to add apply_immediately (at least for staging)? If I understand the documentation correctly, currently if we make changes to the user (or add broker configuration) we would have to reboot rabbitmq manually?

• address review
• review before landing

Now the memoization works in a slightly different way, but achieves the same effect - memoizes the function.
We create a selector, that returns a _memoized function. This function remembers the last action returned for every KeyserverCall. This selector remembers the _memoized function, so it can be used in all components calling useKeyserverCall. If this selector's dependencies change, all actions would have to be recalculated anyway, so it fine that the memoized function is created anew.
This way, we have to memoize less things, because we memoize one function, and actions for all ActionFuncs, instead of a selector and an action for every ActionFunc

We already pass all actions to a hook (even in class components, we use useServerCall) so I imagine there is some way to do it. But I won't insist

Ah sorry, I misunderstood!

The UX change doesn't seem particularly bad to me, but I'd like to understand if the approach you're using here (deleting the old notif) is similar to the approaches that other encrypted apps take. Is there no way to set a "collapse ID" from the NSE?

rebase before landing

Clean up - inline getCallKeyserverEndpoint and invert memoization

address review

rebase before landing

rebase before landing

@ashoat This selector is called inside of actions. I don't think I can use selectors inside of actions, especially that they are called in class components.

rebase before landing

I agree that it would be good to migrate away from the Reanimated 1 API... given it's deprecated in Reanimated 3, we'll eventually need to migrate there anyways. Looking at animateTowards though, it seems fairly complicated... I don't think it makes sense to block @atul's work here on transforming that to the new Reanimated API. We'll probably need to have the Reanimated conversion be a monthly goal for someone...

This health check is only needed by AWS to check if the instance endpoint is healthy. It's more related to ENG-4470.

I'm asking specifically about the health check. It's my understanding that the WebSocket protocol does not have any built-in health checks. Given we're using the Node.js ws library directly on the keyserver side, it seems like we'll either need to switch to using a compatible (Rust-based?) client, OR we'll need to do some additional work on the keyserver to implement this health check. Is that accurate?

Nice, forgot I had already done some of this work!

In D9156#269886, @michal wrote:

Is generic-ness of this is going to be helpful in the future? Or is it going to be always HyperWebsocket under the hood? Because in that case we should just remove the generics and use HyperWebsocket directly

Update port in docker-compose

In D9120#269321, @inka wrote:

Is it possible that a user with this id will not be in our store?

Is generic-ness of this is going to be helpful in the future? Or is it going to be always HyperWebsocket under the hood? Because in that case we should just remove the generics and use HyperWebsocket directly

In D9139#269877, @michal wrote:

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

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

Nice!

Nice! The UI change looks good to me, but letting others review as well.

Use separate tag for staging, bump prod version

Also as I side note, I wonder if upgrading our animation code here to renanimated 2 or 3 api would improve performance. I know that renanimated 2-3 was built with functional components first in mind and IIRC the newer apis have a bunch of hooks to create animations in a more performant way

few questions inline

please see inline comments before landing

please see inline comment before landing

please make sure to check out inline comment before landing