[3.0][Testing] Case insensitive comparisons (part 2 of 2) — guard the convention in the unit suite

[albertlast]

Description

Depends on #9596. It is branched from it, so until that one merges the diff here shows
its commit too. The commits belonging to this pull request are the second and third.

Part 1 gives a comparison a way to say whether it folds case. This is what notices when
one does not say. What makes it worth a test rather than a review habit is the failure
mode: a case sensitive comparison returns fewer rows instead of erroring, so nothing
reaches smf_log_errors, nothing fails in CI, and the first person to notice is a member
whose search came back empty. #9592 and #9593 both sat in the tree for years.

There are two ways to get this wrong, so there are two scans.

1. Folding neither side. The comparison relies on the collation, which folds on MySQL
and does not on PostgreSQL. Counted per file against a baseline:

public const BASELINE = [
    'Sources/Actions/Admin/Bans.php' => 3,
    'Sources/Actions/Admin/Subscriptions.php' => 1,
    'Sources/Actions/Profile/Summary.php' => 2,
    'Sources/Search/SearchApi.php' => 3,
    'Sources/Security.php' => 2,
];

All eleven are real, not noise. Three are #9592, three are #9593, and the two in
Security.php are folded by the ban_like identifier when the query runs rather than in
the query text, so they stay listed with a note saying why.

This scan reads LIKE only. member_name = {string:name} and $member_name = $string
are the same line to a scanner, and an UPDATE ... SET clause looks like both; guessing
would produce a baseline of about fifty entries that are mostly PHP assignments, which is
a test people learn to ignore.

2. Folding only the column. This is the worse one, and it is why the second scan
exists. A folded column can never equal an unfolded value, so instead of matching too much
the comparison matches nothing at all on PostgreSQL — including the row it was looking
for. It also hides, because the query says {column_ci:} and reads as handled. The first scan
cannot find these by construction: it treats {column_ci:} as proof a decision was made.

public const UNFOLDED_VALUES = [
    'Sources/Actions/Admin/Members.php' => 1,
    'Sources/Actions/AutoSuggest.php' => 2,
    'Sources/Actions/Register2.php' => 2,
    'Sources/Actions/RequestMembers.php' => 1,
    'Sources/PersonalMessage/PM.php' => 1,
    'Sources/PersonalMessage/Search.php' => 2,
    'Sources/Profile.php' => 1,
];

These are correct only when the caller folds the value in PHP first, which is a claim
about code elsewhere, so the list names which callers do and which do not. Five do.
Five do not, and are faults: Register2.php and Profile.php are #9594, and
PersonalMessage/Search.php is the same fault in the search for a personal message by its
author, which is not yet filed.

This scan reads equality as well as LIKE, which the first cannot. A line carrying
{column_ci:} is SQL, so an = on it is a comparison rather than an assignment — which is how
#9594 comes into range.

Sources/User.php left this list when #9596 gained {array_string_ci:}, which folds every
value in an IN list, so that comparison folds both sides now.

Confirmed to fail when it should. Adding 'WHERE real_name LIKE {string:x}' to
Sources/Actions/Groups.php:

The set of case sensitive comparisons on user text has changed.
...
     'Sources/Actions/Admin/Subscriptions.php' => 1,
+    'Sources/Actions/Groups.php' => 1,
     'Sources/Actions/Profile/Summary.php' => 2,

A third test asserts both scans find something, so that emptying either one does not leave
the tests above passing against an empty baseline.

Neither scan asserts anything about behaviour, so this is not a substitute for the fixes.
It stops the lists growing while they are worked through, and lowering a number is the
point of them rather than a chore attached to them.

One case is out of reach of both: Sources/User.php:3798 builds
email_address ' . $comparison . ' where $comparison holds LIKE or = from an
earlier line, so neither the column nor the operator is on a line a scanner can pair up.
That comparison folds its values and not its column, the mirror of the second list.

Reading every file under Sources/ costs about 60ms on a normal filesystem (1606 files).
It is slower over a Docker bind mount on Windows, which is a local artifact.

Issues References (Fixes|Related|Closes)

1. Related: [3.0] Case insensitive comparisons (part 1 of 2) — a {ci:} type for the query language #9596 — the {column_ci:} type this guards the use of
2. Related: [3.0]: Email bans do not match members with uppercase in their address on PostgreSQL #9592
3. Related: [3.0]: Searching by user name is case-sensitive on PostgreSQL #9593
4. Related: [3.0]: Two accounts can register on the same email address on PostgreSQL #9594
5. Related: Enable an automated AI reviewer on pull requests (CodeRabbit is free for public repos) #9526 — the same gap this covers mechanically, where an AI reviewer would cover it by judgement

🤖 Generated with Claude Code