I just tried a similar query against enwiki. https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=ids|user|timestamp|userid|comment|size|contentmodel|content&revids=21914234230|3243242|234324

I got:

{
    "servedby": "mw1277",
    "error": {
        "code": "internal_api_error_DBQueryError",
        "info": "[V4amHQpAAEgAAGpfqmwAAAAO] Database query error"
    }
}

I've seen a bug like this before... There it is: T131026#2187446. Apparently having an int-as-string that exceeds the size of the database field makes MySQL decide it can't use the index, so it makes a stupid query plan.

I think I have nothing to do here, you all solved it before I could have a look at it.

Now, I am unsure about the perfect solution- ids are unsigned ints, if you cast it as a long, how do you handle errors? Would it be worth to run min(rev_id), max(rev_id) within the transaction (which are instant returns) to check the values? What is the right reaction, fail or transparently eat malformed parameter? I would support to send (sanitized) ints whenever possible.

Is it a malformed parameter? Are there some docs that specify that the int must be less than 2^32 = 4,294,967,296? It seems that, from the MediaWiki API's point of view, an int is an Integer -- not some digital formalization limited to 32 bits.

It seems that, if you can somehow provide the value as a number in the MySQL query (rather than a string), MySQL handles it just fine. It seems that this is probably the right solution to the problem.

Change 299018 had a related patch set uploaded (by Anomie):
API: Filter lists of IDs before sending them to the database

https://gerrit.wikimedia.org/r/299018

In T140302#2463342, @Halfak wrote:

Is it a malformed parameter? Are there some docs that specify that the int must be less than 2^32 = 4,294,967,296? It seems that, from the MediaWiki API's point of view, an int is an Integer -- not some digital formalization limited to 32 bits.

At this moment, revision ids cannot be larger than 2^32, because right now they are defined as rev_id int unsigned on the database. Whether that is correct or will change in the future, I do not know, I was only stating a fact. If they are larger than that, at this moment we know they cannot exist. Notice I suggested comparing them to max(id) not to maxint (unsigned) knowing that can change in the future.

My question was what to return if a non-existent id was queried? Error or ignore it? While ignore it may be the obvious solution (maybe even the documented one), there is an argument for the opposite: https://en.wikipedia.org/wiki/Fail-fast or to cut options to avoid excessive, useless processing.

Re. "ignore it", that'd be fine if so long as the response includes the "badrevids" parameter for it.

In T140302#2464343, @jcrespo wrote:

My question was what to return if a non-existent id was queried? Error or ignore it?

The thing to do is to do the same thing the API module does if given an in-range but invalid ID. Sometimes that means "ignore it", but for revids it means to include it in a "badrevids" list in the response.

https://gerrit.wikimedia.org/r/299018 takes the approach of specifically filtering the bad IDs out of the database query, leaving it to the existing code to handle it in the same way it handles any other ID that doesn't result in a row being returned from the database.

Thank you for your answer!