T193565 is about making RDBMs code more defensive in regards to such timeouts (which can preemptive PHP method completion anywhere a called function returns). This task is about the broader issue of handling such timeouts. Right now, post-send updates will still be attempted when WMFTimeoutException gets thrown and caught within MediaWiki::run(). DeferredUpdates and Database::onTransaction*() callback handlers loop through updates and swallow/log errors, including such timeouts. A long running DeferrableUpdate would not trigger another WMFTimeoutException after the first one was thrown.

If MW core provided an interface for WMFTimeoutException to implement, then it could be better handled. Conceptually, perhaps:

• MediaWiki::run()/ApiMain::executeActionWithErrorHandling() treated WMFTimeoutException differently by avoiding restInPeace() (e.g. no commitMasterChanges nor deferred updates). There could be a doPostOutputRecovery() method called in place of doPostOutputShutdown() or perhaps just a flag to doPostOutputShutdown().
• MediaWiki::preOutputCommit() could signal that should not be interrupted by WMFTimeoutException during commitMasterChanges() and doUpdates(). This could work by extending the timer by X (e.g. 10) seconds. This would require some kind of service object to make the appropriate Excimer calls (and a stub version of course). The ignore_user_abort() call already exists for analogous reasons.
• DeferredUpdates::doUpdates should halt on WMFTimeoutException errors.
• Database::runOnTransaction*() and Database::runTransactionListenerCallbacks() should halt on WMFTimeoutException errors.

Likewise, Throwable non-Exception errors (e.g. type hint errors) should possibly be treated similarly to WMFTimeoutException in terms of halting vs log-and-move-on. If, for example, an RDBMS/filebackend/externalstore service itself has such a bug, continuing seems unsafe.