@ProcrasinatingReader are you given a warning that One or more of the filter IDs you specified are private. Because you are not allowed to view details of private filters, these filters have not been searched for.?

Cannot reproduce with a private filter: https://meta.wikimedia.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter=1&wpSearchWiki= (shows up for me if I have the rights, not if logged out)
Cannot reproduce with a public filter: https://meta.wikimedia.org/wiki/Special:AbuseLog?wpSearchUser=&wpSearchPeriodStart=&wpSearchPeriodEnd=&wpSearchTitle=&wpSearchImpact=0&wpSearchAction=any&wpSearchActionTaken=&wpSearchFilter=2&wpSearchWiki= (always shows up)

@DannyS712 No - I get "No results". The filter is public and I've enabled all the permissions for my role.

As mentioned in my original reply, I've tried with hardcoded values at that line I specified. Simply changing the array to search for [1] fixes the issue. Hardcoding in ["1"] causes it to break again. So I'm not sure it'd be related to rights or public/private status.

I saw that it cannot be reproduced on meta.wm. I think the fact that it's a local install (hence using SQLite, for ease) might have something to do with it (I'm guessing - hoping - that meta.wm isn't using SQLite in prod). Off the top of my head, I don't think MySQL is strict on '1' vs 1.

I ran manually the query the debug toolbar tells me is being attempted. No results. I replaced "1" with 1, I get results as expected.

This is T253199, and as you correctly guessed, it's because of flexible types.
I wonder how many places in MW code are broken like this on SQLite.

I'll look into this specific issue, but IMHO our DBAL should guard against this; how, I don't know. I don't even think that it's possible to disable flexible typing.

Database::addQuotes was changed to support also ints, when it is given an int. Special:AbuseLog is using explode() and creates strings.

afl_filter is varchar and than the strings in where are okay.
af_id is bigint and that does not work

Maybe it is better to use afl_filter_id in the join, but keep afl_filter in the where (that seems part of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/459818/)

I am not sure why giving an int to afl_filter in sqlite makes it working.

In T255390#6223698, @Umherirrender wrote:

Maybe it is better to use afl_filter_id in the join, but keep afl_filter in the where (that seems part of https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/459818/)

afl_filter_id still has to be written to (although it already exists in the schema). The patch linked above makes a start.

I am not sure why giving an int to afl_filter in sqlite makes it working.

Because, apparently, the value was stored as integer. And this is why the issue with flexible typing is (IMHO) worrying: a single, bad INSERT will require all future SELECTs to account for both possibilities.

https://phabricator.wikimedia.org/diffusion/EFLR/browse/master/business/RevisionReviewForm.php$384

This is also broken. rev_timestamp is a blob, not an integer, so this query also fails to return results. Tested in SQL console with and without encapsulating it in quotations, and the former returned results, the latter (as in code) did not, so I believe that is also related to this.

The advice here should probably be updated:

This configuration is not ideal; better support for this will be built in to the existing dev-image and its tooling.

Whatever the problems with this MySQL usage, I'm sure they can't be worse than using SQLite.

In T255390#6242027, @Proc wrote:

https://phabricator.wikimedia.org/diffusion/EFLR/browse/master/business/RevisionReviewForm.php$384

This is also broken. rev_timestamp is a blob, not an integer, so this query also fails to return results. Tested in SQL console with and without encapsulating it in quotations, and the former returned results, the latter (as in code) did not, so I believe that is also related to this.

The advice here should probably be updated:

This configuration is not ideal; better support for this will be built in to the existing dev-image and its tooling.

Whatever the problems with this MySQL usage, I'm sure they can't be worse than using SQLite.

This task is not about general sqlite support. Please fill one task per issue/extension