[00:14:30] <AaronSchulz>	 TimStarling: anything else for https://gerrit.wikimedia.org/r/c/mediawiki/core/+/771760 ?
[00:15:44] <TimStarling>	 +2
[15:12:17] <Krinkle>	 Amir1: AaronSchulz: Looks like rdmbs error handling may have regressed. https://phabricator.wikimedia.org/T304960#7838458
[15:37:29] <Amir1>	 Krinkle: there is a recent patch that got mergeed
[15:38:00] <Amir1>	 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/777448
[15:38:04] <Amir1>	 Can it be the cause?
[15:39:39] <Krinkle>	 Hm.. are these turning those error codes into the kind that we mark the connection as dirty for?
[15:40:05] <Krinkle>	 or do you think this may fix the bug?
[15:59:09] <Amir1>	 I don't know from top of my head
[16:54:38] <AaronSchulz>	 Krinkle: no, that patch should not effect dirty session state
[17:29:15] <AaronSchulz>	 Krinkle: isKnownStatementRollbackError() controls that
[17:33:22] <AaronSchulz>	 Really, it's only ignoring duplicate key errors that we meant to deprecate. Ignoring timeout errors is maybe OK. The warning is harmless.
[18:39:35] <Krinkle>	 AaronSchulz: I'm not sure I follow. Afaik this deprecation warning is issuees during a query() if the previous query threw and the catcher didn't call rollback. The task mentions two mostly random samples (SpecialLog, ApiQueryContribs) where it seems the main entry point catches the db error timeout, but appears to not have called rollback by the time the error page renders and does its own db query.
[18:40:06] <Krinkle>	 maybe it's not coming out as a db error and instead as a general timeout exception, I guess that explains it.
[18:40:17] <Krinkle>	 but don't we rollback for all fatals regardless of db erorr not?
[20:10:35] <AaronSchulz>	 Krinkle: timeouts only rollback the specific query, so continuing the transaction is OK
[20:12:16] <AaronSchulz>	 (still, it's best to cleanup and rollback for simplicity)
[20:13:21] <AaronSchulz>	 if this is due to a query from UI code before some rollback() call, that's a minor issue