There's no hint to what might have gone wrong here. We will try to reproduce this in production (sandbox entities).
Let's pull specific commits instead of pulling master of wikidata-query-gui into latest, and tag them with a dynamic tag name (e.g month-year)
Looking into T207133: SPARQL service returns entities with broken URLs, seems that we might not need to do this (customize wikibase port) at all.
Rescheduled for deployment 20th of August, with a priory backport
Tested on beta, english wikipedia
This seems to have been resolved. I can access api sandbox on beta, as well as https://wikidata.beta.wmflabs.org/wiki/Special:ConstraintReport successfully.
(mimicking gerrit 😄)
Fri, Aug 16
Tue, Aug 13
@LucasWerkmeister @Smalyshev how does releasing versions of https://github.com/wikimedia/wikidata-query-gui/releases .. there are only two from 2016, but I guess we can release more often, now that we rely on it for shipping wikibase-docker images?
The test has been skipped in T227266: Find out why 'old revisions do not have edit links' selenium test is flaky on CI is being checked for improvements on its flakiness. This task serves no more purpose beyond this point, apart from documenting the same error we are aware of already.
Mon, Aug 12
Scheduled for Monday 19th of August. Fix T230119: New term store connects to the wrong host in clients moved to be tested on beta (to be deployed).
Works as expected in the scenario of self-conflict and of real conflict!
I think the reason is that the graphs are in log scale
can't see where they are in log scale, they are all in time or percentage here https://grafana.wikimedia.org/d/000000615/wikibase-editentity?orgId=1
@Ladsgroup is there a way to test this locally and/or on beta?
Deadline added for the decision, 02.09.2019 end of work day.
Waiting on discussion regarding which direction to go with this.
This will block migration of item terms to new store
This doesn't fix the issue. When testing the updated script with double-redirects, it still failed due to the actual exceptipon being thrown is ItemLookupException and not RevisionedUnresolvedRedirectException.
Since all sub-tasks are in iteration now
@WMDE-leszek 100% agree. I actually was just asking out of curiosity (that that small change would fix the issues mentioned here). We should definitely go down the route of having Wikibase allow to manage a layer of supported languages on top of languages providers that it integrates with.
@Olaf_Simons is this still an issue on your side, or have you managed to fix it?
Waiting on feedback from campers
thanks @noarave for preparing the task description.
Another database access needed to be updated the same way
@stjn good question.
For lead/cycle-times, it can as well be used, but then I need to do two calls to that endpoint to get when the task was created, and to get when it was closed. using maniphest.search kinda was easier here as it gives me both in the response, and it must be as well less overhead on the backend as there's no need to search transaction history for specific changes, I reckon.
that's very nice that you went over the code, thanks!
Fri, Aug 9
For this one, we got back to the original problems we faced with it and why we had to introduce browser.pause in the first place. It appears that sometimes the 1 second we pause might not always be enough, as locally watching the test we could see that the element approached almost a second to appear (at least it didn't feel that instant) so we imagined that it could be in some runs of the test that it takes more than a second which makes it fail, due to invalid form as the keys entered using browser.keys either do not end up in any input (making qualifier input invalid as it is empty) or end up in qualifier property input field (making it invalid too for a wrong property id/label there).
Thu, Aug 8
Wed, Aug 7
is there a way to test this on Beta, or just in production?
One quite expensive way to do this is to define CommonsMedia value type, inject the thumbsize in the value type (by defining CommonsMediaValueParser that takes ParserOptions) and then use it in the CommonsInlineImageFormatter, that would be two days of work at least. Unless I'm missing something obvious.
The mentioned patch has been merged and it failed "only" once due to flakiness in that test. We have a few tests that are still a bit flaky.
This is now failing because Elastic is using that class internally and need to be updated so that it instantiate with the new argument, merge that into master, then run Wikibase's CI again. Though I will look first into comment https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/527015/7/lib/includes/Store/Sql/WikiPageEntityRevisionLookup.php#148 to figure out what to do next. It can be that we don't need the warning after all.
@darthmon_wmde here's what we agreed on to measure as outcome of this:
Tue, Aug 6
Thanks @Ladsgroup for all the investigation so far. Even after looking into hadoop, we cannot identify any specific requests that might be responsible for those spikes. In order to move forward, we will add another layer of caching for property terms for now. If the issue persists or appears again for item terms, then we can invest more time in figuring out the root cause of these spikes.
Fri, Aug 2
@Ladsgroup any new findings you wanna add on this here?
As I will not be able to work on it before next Monday. Feel free to pick up and continue.
Thu, Aug 1
After second deployment, we can see spikes on database (rows per second, but also db traffic) every two hours.