This is a rare case where we can prefer a non-readonly type. In general we want to be "flexible" with the caller. It's more flexible to have read-only types for inputs, but more flexible to allow callers to do whatever they want with the return. Since we are constructing a brand new array in this function, it should be okay to allow the caller to do whatever they want

Thanks for the explanation, makes sense

Where is this type QueryExecResult defined? Is it built into Flow? If so, can you link where it is defined in the Flow lib?

In D7101, I was in the middle of creating a stack and didn't set the parent diff before your review, my bad

Why is this any?

There is no easy way to check flow types in runtime as they don't exist there. On the keyserver, there is simply an Object type returned from the database.
Here I wanted to base this on generics, but without any annotations flow will complain with object type [1] is incompatible with T. I think object is almost the same as any in this context so I think it was better to do it that way.

You should always expect your reviewers to call you out on this, so you should annotate your diffs ahead of time... otherwise, it is a wasted review cycle

I am not sure what is your point if you talking about the fact that I didn't add any explanation - that's fair, I thought it was obvious since it's runtime-related types, but that's a bad assumption from my side.

If you're implying that that's a bad approach codewise, I have two alternatives:

1. remove any and generic T and base on Object.
2. parse each result separately and do sth like:

type ClientDBDraftInfo = {
  +key: string,
  +text: string,
};
function parseDraftResult(result: QueryExecResult): ClientDBDraftInfo[] {
  const { columns, values } = result;
  return values.map(rowResult => {
    const keyId = columns.indexOf('key');
    const textId = columns.indexOf('text');
    if (keyId < 0 || textId < 0) {
      throw new Error('Invalid result: missing columns');
    }

    const key = rowResult[keyId];
    if (typeof key !== 'string') {
      throw new Error('Invalid key type');
    }
    const text = rowResult[textId];
    if (typeof text !== 'string') {
      throw new Error('Invalid text type');
    }
    return {
      key,
      text,
    };
  });
}

but I'm not convinced if this is really needed, I would rather leave it as it is or use 1 and add invariants on results when there will be needed.
LMK what do you think

It might be better to name this something more specific, eg. parseMultiStatementSQLiteResult or something

Or I guess SQLite always returns an array of statements with an array of results with an array of columns inside it?

It might be helpful to assert that T must be an Object. This will help with readability too, I think