[10:21:49] Hi, can someone look into this please? https://en.wikipedia.org/wiki/Module_talk:Mapframe#Too_few_points_returned_when_using_Wikidata [16:50:54] what is this https://phabricator.wikimedia.org/T226271 [17:12:25] It's the thumbnailer being broken. [17:15:54] AntiComposite: I also wonder where the image comes from, as a reverse search does yield results but none on Commons [19:25:36] ToBeFree: May've been a deleted image [19:25:54] but given it's scaled down, I can't use a sha1 based lookup in the deleted image revisions, either. [19:26:00] as it will be different for each resize [19:28:05] Don't know what's going on with that file. Can't seem to restore or upload a new version though - DB transaction times out. [19:28:29] JJMC89[m]: whats the exception ID? [19:29:57] Krinkle: XQ0wCwpAADoAAA7CgmcAAABM [19:29:59] [XQ0wCwpAADoAAA7CgmcAAABM] 2019-06-21 19:29:29: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" [19:30:10] was for a restore [19:32:50] ... that's enwiki [19:33:32] like change the stop opacity from stop-opacity:0.3137255 to stop-opacity:0.3137254 in the one line or someting [19:33:44] oops I accidentally'd the previous line [19:33:57] Yes its enwiki [19:34:00] can't you just upload a new slightly tweaked version of the svg to force a rerender? [19:34:15] I got the file there now by uploading at another title and then moving it [19:34:16] A purge would've likely fixed it as well [19:34:20] I want to know how it got there in the first place [19:34:37] well that would be nice, sure [19:34:39] When i said it wasn't overridden or deleted ever, that was about commons [19:34:44] Let me adjust for enwiki [19:35:51] JJMC89[m]: Wait so what did you do exactly [19:36:13] you deleted the page fully, then tried to restore which failed, then then a normal upload/page create. [19:37:40] Deleted it. Then tried to restore, which failed. Then tried a new upload, which failed. Then uploaded to a new title, which succeeded. Then moved to the the original title. [19:38:50] oh [19:38:55] ok [19:39:41] Still don't know how the face got there though [19:39:58] Could you delete this and try to restore the original upload log instead? [19:40:19] Might take a few tries, but afaik this error isn't deterministic, it's time based so sometimes it's just too slow and we recently made it more strict to abort slow ones [19:40:55] I tried to restore it multiple times before. Got the same error each time. [19:41:04] hm.. ok. [19:41:14] the transaction time limit should probably be raised for undelete [19:41:19] the undelete system is really slow [19:41:29] it needs a lot of love to become faster unfortunately, its really old [19:41:40] it's only got like 3 revisions [19:41:51] undelete for files* [19:42:01] Yes, I run into the issue frequently with other restores. It usually succeeds on a second try though. [19:42:38] yeah, page and edit revision system is much faster and relatively new by comparison [19:46:45] Its taking about 4.15s, which is over the 3s limit [19:48:44] yep [19:48:54] how do you see that though [19:48:59] does it say on the error page? [19:49:35] It says "To avoid creating high replication lag, this transaction was aborted because the write duration (4.3262491226196) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead." above the exception. [19:50:29] interesting, I didn't know we added a UI for that. cool :) [19:50:47] I thought it would just tell you Internal error x12312312313 and then "MWException" or some such [19:52:07]

is Database error. Then the message I just quoted. Then the exception in a red box. [19:52:27] ah, right, we do both for this one [19:52:29] That's nice [19:52:41] I mean, it's not particularly useful to you, but at least you have an idea of what's up [19:52:58] and what the chances might be of getting it below 3.0 s [19:53:02] like if it's almost there [19:53:04] :D