How do we want to adjust the message to resolve this?

Hm, probably we should have special cases of those two summaries for when statements were only added or only removed?

Let’s optimistically close this as resolved, but reopen it if there are more PHP 8.5 issues in WikimediaEvents (not worth opening a bunch of separate tickets for IMHO).

Seems to be fixed, thanks!

Task split looks good to me as well! (And I’m also not sure if Cypress tests will be doable.)

Jinx!

Add acct_creation_throttle_hit equivalent for temp. accounts (T412105) was merged just an hour ago and sure sounds like it could have caused this…

The mw-error.log contains a bunch of errors that look like:

In T411278#11440270, @Lucas_Werkmeister_WMDE wrote:

It might be better to log out through MediaWiki, either via the logout link or using the API?

My feeling is that it helped somewhat, but it didn’t resolve the error completely – I just got it in this build:

@Arian_Bozorg, or perhaps @Lydia_Pintscher or @Alice.moutinho: What should the new edit summaries look like?

And another when looking at an API result (api.php?action=query&prop=revisions&revids=7984):

Screenshot 1:

In T403097#11126732, @Mahir256 wrote:

It seems like resolving T284808 is a necessary precondition for the situation presented in this task.

Still happening, e.g. on this LibUp change. After four months of no response on the upstream issue or pull request (and little other activity on the linked repo either), maybe we should reconsider the use of supertest/superagent in api-testing…

I think we can move this into verification, and the remaining attached change belongs to another task?

In T411278#11440551, @Michael wrote:

Almost all of them seem to use await browser.deleteAllCookies();, which is curious to me because only browser.deleteCookies seems to be documented: https://webdriver.io/docs/api/browser/deleteCookies - Maybe if browser.deleteAllCookies(); is an internal method then that would be consistent with it maybe performing unexpected behavior (clearing localstorage?).

Yeah, the console output looks consistent with that description – the “element click intercepted” error is no longer there but the mw.loader.using wait still times out. Possibly they weren’t related after all? I don’t know.

(Some more discussion about this type of issue is apparently available at T410764, and T390972: Restart CronJobs on failure of the service mesh seemingly attempts to fix it.)

The alert seems to be gone, so resolving. Reopen if there are still lingering issues :)

In T411862#11436124, @Lucas_Werkmeister_WMDE wrote:

That looks like an hourly cronjob to me, yet the age given above is 103m, i.e. over an hour, and it seemingly didn’t re-run yet? Or am I missing something?

https://wikitech.wikimedia.org/wiki/Mw-cron_jobs#Manually_deleting_a_failed_Job says:

This is also blocking deployments (pictured: SpiderPig #1040, unless the deployer is aware of the issue and ignores the canary failures:

This is still logging over 700k messages per hour.

In T411650#11429361, @Lydia_Pintscher wrote:

In T411650#11429346, @Lucas_Werkmeister_WMDE wrote:

Wikibase has a few different configurations for tags: viewUiTags, termboxTags, specialPageTags, and updateRepoTags. Should we introduce a new configuration for this, or is it sufficient to apply the viewUiTags? (In Wikimedia production, viewUiTags and specialPageTags are the same, while termboxTags additionally configures the “termbox” tag.)

Probably viewUiTags is fine but not 100% sure about the logic in the code.

Still happening :( in this gate-and-submit build for this change.

Let’s see if that helps. Please comment here if you still see either of the errors mentioned in the task description!

Wikibase has a few different configurations for tags: viewUiTags, termboxTags, specialPageTags, and updateRepoTags. Should we introduce a new configuration for this, or is it sufficient to apply the viewUiTags? (In Wikimedia production, viewUiTags and specialPageTags are the same, while termboxTags additionally configures the “termbox” tag.)

In T349276#11390304, @bd808 wrote:

Just a drive-by idea: an optional, durable cache could be added as a volume rather than a bind mount to local disk. Containers could be named with a pattern (fresh_npm_cache...) that made them relatively easy to discover with {docker,podman} volume ls.

On a successful run, the video looks like this:

Ok, I think I finally figured out the issue from this video of this build:

hook behaviours into wikibase.entityPage.entityLoaded and wikibase.statement.saved hooks

Also, apparently the entity search calls aren’t debounced at all? So searching for linked-property-0.33714683744760543-Iñtërnâtiônàlizætiøn, one keystroke at a time, makes some 63 wbsearchentities requests practically simultaneously /o\

Weird result: when I run the test locally, sometimes the first two characters typed into the lookup get lost:

Pulling into our board as a high-priority CI issue.

The message is Template:Abusefilter-warning-mp3, caused by abuse filter 192: Restrict MP3 uploads. Nothing to do with UploadWizard, except perhaps that the layout could be better. (Also, note that mp3 became patent-free in 2017, which is not the same concern as copyright.)

Also failed here (blocking vendor: drop PHP 8.1 support) with the same error as in the task description.

Moving this into Ready for Peer Review – one or two changes at the very end of the chain still need a bit of work from me (anything that says “TODO” or “WIP”), but the rest should be okay to review and merge already and we should really start to get this chain of changes shorter instead of longer ^^

In T388228#11423184, @kostajh wrote:

Another flaky test: editEntityDatatypes.cy.ts, seen on https://integration.wikimedia.org/ci/job/quibble-with-gated-extensions-selenium-php83/779/console

Same test failed in this build with a different error:

The “element click intercepted” also happened in this build without an associated “mw.loader.using is not available” error (as far as I can tell). (It’s not actually clear to me if that error caused the build to fail, or if it failed for unrelated reasons.)

Task time notes:

Task time notes:

We saw one counterexample in the showcase meeting today – if you make an error, then correct it and successfully save the statement, the error message can still be there. Alternatively, you can cancel the current edit, and then you’re also back on the “main page” (statement list) and an error message is shown.

How exactly did you go back to [[WP:Sandbox]] (last step)? The URL shows you still on auth.wikimedia.org rather than en.wikipedia.org.

@Alice.moutinho BetaFeatures supports separate images for LTR and RTL languages; do you know if there’s a “mirrored” version of that image available (and/or if that would even be appropriate), or should we just use the same image everywhere?

Note that the current behavior matches the desktop UI, where you can also add statements to the “wrong” section and they’ll “jump” to the correct place when the page is reloaded. I feel like we have a task for fixing this, but I can’t find it at the moment; in T117421, this behavior was added to the task description: “It is possible to add an identifier in the statement section or vice versa. It will jump to the "right" section on page reload.”

In T392023#10745674, @Jdforrester-WMF wrote:

This is odd. We're setting rc_actor, and the logged context says we are, but it's not coming through?

Exception executing job: wikifunctionsRecentChangesInsert […] user=8776 bot=0 requestId=4c0e314e-c844-4315-bcd4-b88e3780e333 : RuntimeException: At least one of user ID, actor ID or user name must be given

Failed screenshot (though it doesn’t really add anything beyond the console output, I think:

Resolved, I guess, unless someone else finds a similar error.

Also failed in this build for property prefix search:

Resolved, as @Tgr added ExtensionRegistry to MediaWikiServices two years ago.

CC @hashar (tests: skip tests when ConfirmEdit is not loaded) and @Dreamy_Jazz (Return early from CaptchaScoreHooks if ConfirmEdit not loaded) from T410126: WikimediaEvents tests fail when ConfirmEdit is not loaded.

In T411278#11416485, @gerritbot wrote:

Change #1212615 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] DNM: Empty change to test CI

https://gerrit.wikimedia.org/r/1212615

In T411278#11416484, @Lucas_Werkmeister_WMDE wrote:

This repeated build failed in exactly the same way – this might be brokenness rather than flakiness…

This repeated build failed in exactly the same way – this might be brokenness rather than flakiness…

In T409828#11415232, @ArthurTaylor wrote:

I think @Lucas_Werkmeister_WMDE's suggestion was to immediately dismiss any messages when the form reopens - mine was to move the messages up so that the buttons are not covered. Which of those do you prefer?

Fixed (Cognate, InterwikiSorting), thanks @hashar!