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.

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.

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

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.

I think this alone is about a 5 pointer

I reckon this is about a 5 point task- ish

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:
https://logstash.wikimedia.org/goto/aa869fe7c18571f288fbb8afd45d582a

More details logging of the request parameters is now available since yesterday.

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

In T228978#5375173, @Addshore wrote:

Although #1 could en changed to register a new parser option called wb-termbox for example, default value null, used in cache key and when termbox is rendered set it to 2.

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.

@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 )

2. 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:
On page
[XTg6eQpAME0AAB7XveAAAAAC] 2019-07-24 11:01:13: Fatal exception of type "RuntimeException"

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