Read a query-log entry's keys directly, now that core types getLog() as a shape and the coalesce beside them is dead code
Fixes #3620237.
phpstan (next major) went red on 1.x with five identical errors, in five query-budget tests, without a line of orchestra changing: the same code passed the same job on 2026-08-30 and failed on 2026-09-01. Core moved.
Database::getLog() is documented as returning a plain array on 11.x and a list of DatabaseLogEntry on main, and DatabaseLogEntry is a @phpstan-type alias in Log.php for an array shape naming all six keys an entry carries. Once the entry has a shape the analysis can see that query and args always exist, so the ?? beside them is unreachable.
They do always exist: Log::log() writes all six on every entry. Nothing here is a runtime change, which is why phpunit (next major) passed on the very pipeline the analysis failed on. The coalesce was never catching anything.
Safe on both lanes, for different reasons. On main the shape says the key is there. On 11.x the return type is a plain array with no shape, so reading a key without a coalesce raises nothing at level 5 either.
| file | was | now |
|---|---|---|
ConditionalFlowsTest.php |
(string) ($entry['query'] ?? '') |
(string) $entry['query'] |
TokenCancellationTest.php |
$entry['query'] ?? '' |
$entry['query'] |
InstanceTimeoutAnchorTest.php |
$entry['args'] ?? [] |
$entry['args'] |
MyTasksViewTest.php |
(string) ($entry['query'] ?? '') |
(string) $entry['query'] |
PendingActionsFinderTest.php |
(string) ($entry['query'] ?? '') |
(string) $entry['query'] |
Locally: phpcs clean, and the five affected classes pass. The proof that matters is both phpstan lanes on this branch, which I will play.
One thing worth keeping in view beyond the fix: the job is allow_failure, so the pipeline for the merge commit reported success with this red inside it. A lane that tracks core main can turn red on a day nobody touched this module, and the badge will not say so.