Great!

Sure

Might be good to create (and link) a task here to investigate that issue

In D9143#270092, @inka wrote:

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

boundCallServerEndpointSelector is called inside of callKeyserverEndpoint, which is being called inside of the function returned by ActionFunc. This would be equivalent to being able to use a selector inside of callServerEndpoint, which I don't think is possible.
Sorry, I think I called an action the wrong thing maybe.

Requesting changes to make sure I at least get a satisfactory explanation before this lands (ideally a proper solution)

New dependencies look good. Rust code looks simple, but will leave it for somebody else to review

JS code looks fine but I don't really know anything about gRPC interceptors... should somebody else with context on those review this as well?

If you want to keep the change to Metadata (or disagree with any of the other comments), please re-request review

Nit – we usually use } else if in reducers. It doesn't matter since each condition returns, but it would be good to be consistent

Please make sure to address the last two comments before landing

Got it, let's keep the WHERE. Only feedback to apply here is stripping the semicolon.

(toggleMessagePinForThread changes can probably be in a separate diff)

Interesting that toggleMessagePinForThread is missing the threadInfo.sourceMessageID !== item.messageInfo.id check. I guess that can't happen, since it only takes a messageID, and the parent channel gets fetched from that (rather than the corresponding sidebar).

I don't think your original approach of having a fixed length ThreadRolePermissionsBlob makes sense based on commentary here. This would require a separate "position" for every single combination of prefixes, which would likely be a very "sparse" matrix.

Looks good, just a question:

Ah sorry, I thought this was updating web and native, but it's actually updating two places in native. We should obviously factor this out so we're not copy-pasting code, but I suppose that will be handled in the subsequent diff (as indicated in the diff description)

How come this adds isInvalidPinSource for both web and native? Is that because the diff that adds it to one and not the other hasn't been landed yet? Does that diff now need to be abandoned?

Lint fixes

I tested performance again and it's about the same as it was in the last revision of the diff

1. @tomek’s nit about ordering about conditions
2. @tomek’s feedback about not needing a stack for exact match
3. @tomek’s feedback to use a map from first char for children (instead of an array) to improve perf
4. To maintain compatibility with old approach, I updated the code to "dedup" identical values using Sets
5. To reduce unnecessary memory usage, I got rid of leaf: false

Please don't land this without creating follow-up tasks

I ran this query in my local environment, which includes a copy of my keyserver's production database from last month. It matched 904 rows and updated 40 rows. It only took 0.122s to complete!

Both queries had great performance!! The SELECT took only 0.009s, and the UPDATE took even less (0.006s)

It might make sense for @marcin to take a look at this given his experience with notifs

cargo-lipo is still referenced in scripts/ensure_rustup_setup.sh – would be good to clean that up

I ran this query to make sure admins don't have descendant_open_voiced and it looks safe:

I think it would be good to test the query in production before landing this. In particular, I'm curious how long it takes. Two ideas come to mind: