[{reqId}] {exception_url} PHP Deprecated: Caller from MediaWiki\Page\PageStore::getPageByNameViaLinkCache ignored an error originally raised from MediaWiki\Specials\SpecialRecentChangesLinked::doMainQuery: [1969] Query execution was interrupted (max_staWhy are these PHP Deprecated? It's unclear what is supposed to be done... If anything
[{reqId}] {exception_url} PHP Deprecated: Caller from MWExceptionHandler::rollbackPrimaryChanges ignored an error originally raised from MediaWiki\Pager\IndexPager::buildQueryInfo (contributions page filtered for namespace or RevisionDeleted edits): [19We don't own the code, I didn't write that part (maybe moved it around). This is on Mediawiki interfaces team.
The first error is T304085. Not sure what the second one is about, maybe the same thing?
There's maybe 4 or 5 that I've been seeing appearing over the last week... Just very unclear what should really be the action etc
What this error means is that some code (usually the code in "originally raised from", not the logged stack trace) is catching a DBQueryError which is not a supported operation.
This looks like T304960: PHP Deprecated: Caller … ignored an error originally raised from IndexPager::buildQueryInfo (LogPager, SpecialLog) or ApiQueryUserContribs::execute. From there:
This is a confusing deprecation warning, and causes log noise. What is happening is that we have code (IndexPager::buildQueryInfo) [...] that runs a query. This query can sometimes time out after 30 seconds. [...]
The code is then mishandling the timeout error, and as a result the next code to run a query encounters the Deprecated: Caller … ignored an error originally raised from warning from Rdbms.
This indeed similar to T304085: PHP Deprecated: Caller ignored an error raised from SpecialRecentChanges::doMainQuery (max_statement_time exceeded), however SpecialRecentChanges and SpecialRecentChangesLinked each have their own setMaxExecutionTime() call. And, depending on whether the fix will be there or in the shared ChangesListSpecialPage class, may also each need to handle database exceptions correctly.
I guess we can exempt statement rollbacks of read statements due to max_statement_time from the logic triggering setTrxStatusIgnoredCause(). Any try/catch for timeouts should only exist when fairly directly wrapping a single read query.
In case of misuse of try/catch (e.g. when calling complex methods that do many of their own reads/writes), atomic sections would help guard against incomplete transactions (when methods abort early due to exceptions).