Thu, Aug 15
I think the conclusion we have come to is to occasionally monitor this but as per the discussion with Joe we'll not actively work on it unless it becomes more of a pain point.
While double checking that this was sufficient load we discovered that since the estimations were done last year the mobile load on wikidata.org has increase.
We successfully ran the load test from around 10:30-11:20 UTC on 2019-08-14. Over an ssh tunnel between a developer laptop and eqiad.
Wed, Aug 14
Tue, Aug 13
Mon, Aug 12
This sounds like a good plan. To me we should be also running the php linting/fixing at the same time in this case though.
Fri, Aug 9
Thu, Aug 8
Adding another example of a flaky test:
https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php70-docker/27043/console (https://phabricator.wikimedia.org/P8888) for posterity
Wed, Aug 7
Today we also spoke to @Ladsgroup and concluded that we could smoke test live on eqiad production. Given that it is only needing to perform to 1 request /s and we probably won't test above 5.
Tue, Aug 6
I think this alone is about a 5 pointer
I reckon this is about a 5 point task- ish
Mon, Aug 5
Thu, Aug 1
From IRC @Joe and I talked:
<_joe_> Giuseppe Lavagetto it might be due to some congestion on the link, or some other cross-dc issue 11:14 AM 100 errors in 3 weeks is well below the limit where I start investigating though :) 11:15 AM <tarrow> Tom _joe_: right; it's just that right now the only traffic hitting it is the healthcheck service. We're wondering if that will spike once we have real traffic 11:16 AM <_joe_> Giuseppe Lavagetto possibly, but when you'll have real traffic there, it will be because mw is active-active, so api-ro will point to codfw :) 11:16 AM so no more cross-dc latencies etc.
Picking this up again. Will work on the existing patch;
In the last 24 hours there is now some data:
Wed, Jul 31
More details logging of the request parameters is now available since yesterday.
Tue, Jul 30
Had a call with @Addshore:
@Addshore: can you take a look at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/526117/4 in comparison to https://gerrit.wikimedia.org/r/526174
Mon, Jul 29
I think that would probably not work that well. We don't really want to provide editors with a mixed old/new experience where they can edit some items but not others.
Just to clarify the two options we thoughts of are https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/526117/3 (not 2) and https://gerrit.wikimedia.org/r/526174
@Jakob_WMDE and I spent quite some time looking at it today. We came to the following discoveries.
Fri, Jul 26
@Lea_WMDE It should be on beta now :)
I took the following extra details from figma:
- Height of the progress bar is always 20px
- From the two examples it appeared to be as close as possible to horizontally and vertically centered so I did this
- box-shadow is added
- border colour is as specfied (#A2A9B1)
This is now perfectly reproducible locally. ( We were caught out by $wgInvalidateCacheOnLocalSettingsChange )
Thu, Jul 25
- When data load from the storage contains entries using a language code that is not recognized by Wikibase, those entries must not be presented to the user (e.g. for reason X there a label related to the invalid language code stored in the DB,
@Jakob_WMDE was unable to reproduce locally; toggling the UseSSR variable always seemed to result in refreshing the cache
Copied information from the other task:
[XTg6eQpAME0AAB7XveAAAAAC] 2019-07-24 11:01:13: Fatal exception of type "RuntimeException"
Wed, Jul 24
Saw this suspiciously in the local logs:
Fixed by action=purge ing the page
I see it only so far in the logs for Q7 and Q173121