[08:18:03] aude: oerhaps you know, what is the current delay before an automatic purge in the clients after an update on wikidata? [08:18:15] perhaps… [08:18:26] or anybody else [08:25:52] jeblad: as I understand it, it varies between wikis and I don't know how to find out what it is for a specific wiki. if I understand https://www.wikidata.org/wiki/Special:DispatchStats correctly, it could be anywhere between immediately and 15 hours [08:27:07] (I think cebwiki is currently quite lagged because a bot was creating lots of items for cebwiki pages, so that's probably just an outlier) [08:28:53] this is endless... [08:30:23] nikki: mean on a graph with outliers… :D [11:37:51] has something changed with the query service rate limiting? I just got some rate limit errors despite only running one query and that's never happened before even when I'm doing multiple queries at a time [11:44:52] and again... [12:34:13] PROBLEM - High lag on wdqs1001 is CRITICAL: CRITICAL: 31.03% of data above the critical threshold [1800.0] [12:59:42] ACKNOWLEDGEMENT - High lag on wdqs1001 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [1800.0] Gehel wdqs-updater restarted, lag should come down [13:00:46] nikki: yes rate limiting has been enabled Monday, you should not be limited when running only 1 query at a time, let me check the logs [13:01:02] it seems to happen after a query times out [13:01:34] nikki: that might be the case, you might consume all your quota with a query expensive enough to time out [13:01:58] what is the quota? [13:02:20] and that sounds annoying when we don't have a way to cancel queries :/ [13:02:27] 1 minute of query per minute [13:02:37] with burst at 2 minute of query per minute [13:05:13] it's bad enough that I'm expected to sit and wait a whole minute for it to time out every time I make a mistake without making it so that I have to wait even longer because I've been rate limited :/ [13:05:15] nikki: yep, I understand the annoyance... the alternative was to have the service slowdown to a crawl when under too much load... [13:05:42] nikki: we might tune the limits a bit higher... [13:06:06] the goal is obviously not to annoy legitimate users, but to block abuse... [13:10:47] nikki: not that the limit is per server, since your queries are randomly assigned to servers, there is a good chance that if you retry, it won't be blocked [13:23:32] RECOVERY - High lag on wdqs1001 is OK: OK: Less than 30.00% above the threshold [600.0] [14:19:35] +1, a way to cancel queries before they time out would be very nice :) [14:20:20] (I have no idea how much effort this would require - I suspect it isn't just as simple as adding a button) [14:23:57] * dbs waves from the wikidata table at wikimania [14:34:49] pintoch: i'd imagine they'd merely have to cancel the ajax request [14:35:27] (if you're talking about the query browser) [14:45:57] ciss: yeah, but is that enough to actually stop query execution in the backend? [14:48:32] ciss, pintoch: it’s complicated :( https://phabricator.wikimedia.org/T136479 [14:55:33] pintoch: nope, but i'd consider that a slightly different issue [15:00:24] pintoch: on the other side, the process of manually aborting a query in the query browser is somewhat involved: copy the query, reload the page, paste the query. and for that, the fix should be reasonably simple (imo) [15:01:04] ciss: yeah but you don't want to implement that fix without cancelling the query in the backend, it would be a waste of resources I think [15:03:34] Lucas_WMDE: thanks for the link :) [15:10:55] pintoch: a workaround would be to set a limit on when a query can be cancelled. e.g. disable the (imagined) "abort query" button for the first 3 or 5 seconds to prevent spamming. that would still be longer than the time it takes a user to perform the three steps i outlined above. but since it's the more comfortable way, users might be more inclined to wait til the button enables. [17:53:06] Envlh: dispo pour créer des tickets si tu veux [18:48:02] hey, just finished setting up a wikibase install from scratch using master mediawiki / master wikibase extension, but once I enable wikibase every request fails with a database query error [18:48:32] mariadb, innodb, utf-8 charset, running on ubuntu 16.04 [18:52:03] initial errors look like: https://pastebin.com/gHevGHbk - maybe a recent change to master, or maybe my environment :) [18:52:39] I'll be back at the hackathon in half an hour or so if anyone wants to inspect [19:35:30] Lydia_WMDE: fyi, there's still more wikidata-related open blockers for this week's train: https://phabricator.wikimedia.org/T170631 I think the plan now is to just continue on without updating wikidata again [19:36:13] greg-g: we are aware and can focus on them at the hackathon [19:36:24] * aude was busy / travelling the past days [19:36:51] aude: /me nods [19:36:52] thanks [19:37:27] yeah [20:01:51] cloud is already investigating on stashbot [22:41:07] * dbs suspects that wikibase requires binary collation, instead of utf-8 - thanks to aude (i think?) for the assist [22:50:10] That was me ;) [22:50:25] Couldn't find a bug about that… will open one later today/ tomorrow [22:50:32] unless someone beats me to it [22:52:51] hoo++ [23:35:17] I need somebody to undelete https://wikidata.beta.wmflabs.org/wiki/Q81561