Followup task: https://linear.app/comm/issue/ENG-4402

Rebase

Inline getChatThreadItemSize

Seems like unsigned int is the official type, and uint is typedefs by some compilers automatically

Are we already explicitly using c++17 in native (not c++14 with extensions for 17)? If not it would be good to use it.

Looks good, just some questions:

• would it make sense to make these methods more inline with others? So e.g. setPersistStorageItem getting PersistItem as an argument, or getPersistStorageItem returning PersistItem or null instead of string?
• can we test these methods, and amend the test plan?

Refactored the code, used a similar approach as it's used on native (union with item type). Extracted search to a separate component.

We are changing the approach for this task, so I'm abandoning this diff. More info in the linear task.

We are changing the approach for this task, so I'm abandoning this diff. More info in the linear task.

We are changing the approach for this task, so I'm abandoning this diff. More info in the linear task.

Yeah, use of this any is contastrained to this one specific migration, and it's used as a function passed to other functions (that are typed correctly) so it shouldn't 'infect' other code

LGTM, but I'm not confident in db code, so adding for varun as blocking for this one

Replaced types with any as discussed in D8355

I've readded the types. MediaValidator needed to be special cased because of flow issues (that's the same issue as @bartek had). The types are replaced with any in D8386.

There's actually another problem: the generated functions can't be typed with our types because they will get out of sync. What I mean by that is that these functions operate on data that is stored in sqlite/redux at this point in time. If in the future someone modifies e.g. RawMessageInfo then this new type could conflict with the generated functions' body and make a flow error.

Use hasMinCodeVersion from the previous diff. Don't split NEXT_CODE_VERSION per platform as it's not needed anymore.

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: