Rebase

Move NEXT_CODE_VERSION changes to D8386

I've also checked the converted db with the validators:

const { messages, threads, messageStoreThreads } =
        await commCoreModule.getClientDBStore();

Extracted logic into two functions - one for threadID and second one for messageInfos.

Use keyserverPrefixID

Address review.

Fixed comment

Removed some uses of any, and annotated the rest. Additionaly:

• here's a minimal repro of the error: flow playground
• this is handled in the same way as we handled the error in D7488

Update summary

Moved all state version bumps, and FUTURE_CODE_VERSION replacements here, so nothing will break if we land only part of this stack.

Get all stores at the same time and await all updates concurrently. Extract conversion functions.

Update the migration functions so instead of fetching the stores, they take them as an argument and return operations.

Address review

Address review

Handle other auth actions

Respond to review

Set new platform details concurrently with policy validation. We need to block execution before running endpoint logic, because it might depend on the version

Looks good, we could potentially use reqwest:Url and .set_port(), .join() for URL manipulation.

Added converters for ConnectionInfo and CalendarFilter

Add rootKey

LGTM too!

Improve any-casts. Now they are cast immediately to the correct type, similar to how it is done in lib/utils/validation-utils.js. The main problem is that flow doesn't constrain th TType to one of it's variants (e.g. TInterface or TUnion) after checking the meta.kind field so we need to do that ourselves with the any casts.

Await the setCookiePlatformDetails

In D8355#246571, @ashoat wrote:

2. I worry that the codegenned file might get out of sync with its inputs. Before landing, can you create a Linear task to add a CI job that regenerates the file and confirms there are no changes? We should make sure we complete that task before we ship this project.

I suspect this is going to throw an error if you close the window without closing the whole app (macOS-style) and run the new menu option. You could probably use the global mainWindow for inspectSharedWorker (with a check if it exists) instead.

A small thing, and shouldn't matter performance-wise, but you should be able to take the range_header variable as a reference in the function, instead of taking it as an owned value and cloning it with to_owned().

Nit: I don't we need the two // Parse range header comments, now that we have a function with the same name

We could merge the two top-most matches and remove unnecessary clone like this:

let (range_start, range_end): (u64, u64) = match &range_header {
    Some(web::Header(Range::Bytes(ranges))) => {
      if ranges.len() > 1 {
        return Err(ErrorBadRequest("Multiple ranges not supported"));
      }
      <...rest of the code...>
   }
   Some(web::Header(Range::Unregistered(..))) => {
      return Err(ErrorBadRequest("Use ranges registered at IANA"));
    }
    None => (0, file_size - 1),
};

which I personally find a little easier to read

Instead of using another variable, could we pass query to appendResults and check if it's still the same?

Do you think it would make sense to:

The dockerfile needs to be built with the context of the root folder (because it's a member of the yarn workspace) and it's on dockerhub so we need to keep track of the current tag/version. To me, it makes sense to keep track of that in a docker-compose.yml.

Makes sense, thanks for explaining

Also, the query won't be cleared if you manually remove text in the textbox (compared to clicking the X button) which I think I would find confusing.

Not sure what the status of the "Search" button is, is the plan for it to be implemented in other search modals too, or is it just a one-off? Do you think it would make sense to add it (as an option) to the SearchModal?

Updated to reflect changes in D8073, fixed an issue where sometimes threads wouldn't display.

• Fixed small issues
• Instead of passing joinedThreads to fetchMessageInfo I instead add a condition to the sql query role > 0 (more context here)
• On the client threads are sorted according to lastUpdatedTimeIncludingSidebars. This means that:
  • we could fetch last message for a sidebar
  • client still doesn't have messages for the parent thread, so it's not displayed
  • later client scrolls down and fetches last message for the parent thread
  • parent thread in displayed, but it jumps up because it's sidebar has an earlier messages To fix that I also fetch the last message for parent threads of any sidebars. This complicates the lastMessage logic (I now have to filter the additional parent threads) so now it's done on the server and passed to the client.

Moved all conditions (version has to be newer, release has to have assets) to the find condition instead of skipping them after one release is chosen. This way we don't ignore the rest of release from github api

Fix flow

Rebase

Catch errors

The output validation looks good but you also need to modify the input logic.