Software developer on the Wikidata team at Wikimedia Germany (he/him, Berlin timezone). Private account: @LucasWerkmeister.
User Details
- User Since
- Apr 3 2017, 2:45 PM (363 w, 19 h)
- Availability
- Available
- IRC Nick
- Lucas_WMDE
- LDAP User
- Lucas Werkmeister (WMDE)
- MediaWiki User
- Lucas Werkmeister (WMDE) [ Global Accounts ]
Thu, Mar 14
I also lean towards increasing memory, see T356402#9623035.
Thanks! Now T345319 is back at the top of the error log (and will apparently be fixed next train, nice).
Processed 5810400 (updated 11) of 19417998 rows --start '["14615766"]' Processed 5810500 (updated 11) of 19417998 rows --start '["14615874"]' ^C
I just tested email sending for T359188 (Gerrit change and it’s already broken again (actions run):
There’s one more case I just thought of:
Assuming that the screenshot in the task description is from the Parsoid Health Grafana dashboard, this seems to be resolved:
Tentatively tagging #mediawiki-external-store and DBAs for now…
Should be fixed via backport of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1010932 (attached to T359509).
Wed, Mar 13
I think this is resolved; we can leave the task open for potentially adding a test, but it’s no longer a train blocker.
In ?debug=2 mode, I can see that the load.php URL for modules=user is no longer loaded. (If I load it manually, it still responds with the same JS as before.)
I’m able to reproduce the issue locally; git bisect points at ResourceLoader: Add preload for foreign WikiModule title info as the first bad commit.
Also affects Commons (another group1 wiki/).
Tentatively tagging ResourceLoader, I think RL is responsible for loading this code (and I know it was refactored a bit this train).
(Merging into T360014 because that one was already marked as a train blocker.)
Tue, Mar 12
All the attached changes are merged – was there anything else left or is this done?
T359939: PHP Warning: Illegal string offset 'page_len' seems to be new in this train, though I’m not sure it’s serious enough to be a train blocker.
On the one hand, I can see that it's good to run the tests in the same constrained environment that we run production in - not doing that will cause some issues to slip through the testing net.
viwiki is still running and successfully updated one page, apparently:
Prio Notes:
Prio Notes:
Prio Notes:
Prio Notes:
The result looks like this, by the way:
This seems like it should be prioritized by Product.
Prio Notes:
Prio Notes:
Prio Notes:
Prio Notes:
Thu, Mar 7
I think NoBadUsageTestBase would work for cases where we want to prevent PHP things (e.g. DB_MASTER instead of DB_PRIMARY), but for such a general check, I’m not convinced it’s worth checking automatically.
@Arian_Bozorg this is probably a relatively simple fix (define a few more i18n messages), do you want to put it on the product backlog?
Impact Area | Affected |
---|---|
production / end users | ✘ |
monitoring | ✘ |
development efforts | ✔ |
onboarding efforts | ✔ |
additional stakeholders | ✘ |
I don’t think this is a Wikibase problem at all; the non-interactive Kartographer map, and console error message, can also be reproduced on e.g. https://de.wikivoyage.org/wiki/Hallstatt?safemode=1.
There's definitely better way than doing this...
The linked SonarQube issue was apparently resolved in v8.7 (2021); a recent codehealth run for Wikibase shows some other analysis errors (java.lang.NullPointerException: Cannot invoke "org.sonar.plugins.php.api.cache.PhpReadCache.readBytes(String)" because "<local2>" is null on lots of PHP files), but no errors in Vue files. Let’s assume this is resolved.
I’m confused, why are we saying this is a bridge test? The pasted output says it was repo/tests/selenium/specs/readmode.references.js, which is something in repo unrelated to Bridge (which is in client).
This is probably superseded by T359253: Migrate MediaWiki.$prefix.wikibase.client.scribunto.* to statslib now?
Prio Notes:
Wed, Mar 6
Trying viwiki again, to see if the “no server with index” errors went away; so far it looks okay (though it hasn’t actually updated anything yet, and the previous stack traces ended in insertThreadItems(), so maybe the problematic code hasn’t been hit yet):
Not sure, no. But “No server with index '0'” sounded like a problem related to the load balancer configuration.
Hopefully not a big deal, I think.