I have no idea how to handle this at best. The loop would be a workaround, but that sounds okay. Is npm audit giving an return code when there is still something to fix? But also without it calling it twice would be okay.

The same blob number on zhwiki also mention under T212428#4886442, possible a duplicate

UploadBase::mTempPath is documented to have null values, nothing more to fix from my point of view

There are also other issues on action=upload with big files, see T278389 or T280926, possible all related

On AbuseFilter is now twiced updated for hosted-git-info possible by this problem

• Second - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/686753
• First - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/686402

rev-suppressed-text-permission is only used on Special:Undelete. All other places does not make a different between normal and restricted, if the user is not able to see the content.

The api shows that the database contains

Happen again:

Removed as part of https://gerrit.wikimedia.org/r/c/mediawiki/core/+/630299

There are some changes to Message::toString - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/681818

The upstream sniff PSR12.Functions.ReturnTypeDeclaration is for PS12 without spaces between ) and :

That sounds okay to me, too.

Happen on canary right now: https://libraryupgrader2.wmcloud.org/logs2/256097

Other places to remove some pieces

The fk no longer exists, see T164898 - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/678426

Type hints were added in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/676444

When Content::getSection fails in EditPage::getContentObject it is returning $def_content which is null here.

Could fail on wmf/1.36.0-wmf.38 as well (suggest no backport)

The message is in the flow extension at:

This can happen since https://gerrit.wikimedia.org/r/c/mediawiki/core/+/554947

Regression from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MassMessage/+/649670

the mention files here are tests files and test files are not part of the package. There is no message when using the older package as well.
From my point of view there is nothing to fix.

Now part of 36.0.0

There is logging in the code (UploadFromChunks::updateChunkStatus), not sure if that can be found for this request:

That will be fixed as part of T281340, there is nothing which could be fixed here, because the error was happen on a rollback / error situation already.

It looks like the data stream was interrupt and the server assumed a connection closed by the client.

The merged patch set does not fix the problem with $mTempPath not set, but it avoids the notice/failure.

In T271356#6999838, @thcipriani wrote:

Still seen as of 2021-04-14. Seen 63 times in the past 24 hours. Primarily on fawiki, but seen across wikipedia versions on 1.36.0-wmf.38

For me it is https://test.wikipedia.org/wiki/Special:NewPagesFeed where the resource loader module with that script is loaded.

Now shows:

Bad Request
Invalid ID: M4.

In T273808#6901965, @Umherirrender wrote:

Are there still issues in the logs?

Error is thrown here: https://gerrit.wikimedia.org/g/mediawiki/extensions/Kartographer/+/ef6964df043285e91fb7c6e69ff48c9db2969582/lib/external/mapbox/mapbox-lib.js#1720

There is a note about this on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/663327

Note: The fieldset legend is not parsed when it should be.

There is a feature to move subpages on Special:MovePage, but that is typically not enabled in the template namespace, because the namespace itself is not a page which allows subpages (by definition of mediawiki)

In task description:

the "protect" right i.e. "Change protection levels, edit and move protected pages, and edit cascade-protected pages"

There is no Special:Protect. Did you mean action=protect or Special:ProtectedPages or Special:ProtectedTitles?

eslint also allows caching and it is enabled on all repos, but there is not a task to enable/use the cache on CI for eslint.

Now also coverage is ignored (done by https://gerrit.wikimedia.org/r/c/mediawiki/tools/codesniffer/+/681483) and libup can remove it, for this part the version is v36.0.0 (release planned as of this now)

Not sure if #searchText could be omitted on a page view, but this is the closed code I have found in the javascript URL1

searchWidget=OO.ui.infuse($('#searchText'))

https://gerrit.wikimedia.org/g/mediawiki/core/+/04956b4349513f8072dc803586533aa39f6c9938/resources/src/mediawiki.special.search/search.js#24

Without spaces to work for me:

		"test": [
			"@lint",
			"@phpcs",
			"minus-x check ."
		],

In T277331#6973330, @Jdlrobson wrote:

Also occurs on action=delete and Special:GlobalPreferences presumably for other reasons.

I am not sure if that race condition is tracked by the moved code.

In T273354#7011442, @Func wrote:

In Change 680687, @Umherirrender wrote:
Returning false with that value acts the same as returning true with a fatal Status?

Why this change? What does this change fix? Is there an error with the hook to fix?

If this is for the deprecation of the fatal Status usage here, that should be done with a deprecation cycles.

@Umherirrender, I noticed that you commented on Change 680687 before here (in the order of emails)?

1. Not only "that value", but also any customized status value can work to display error message properly on mediawiki version 1.36 and before. Not required to set the value now, just for backward compatibility.
2. Changes related to T280312 are aim to display error message to user properly, maybe I didn't explain it clearly in commit message.
3. These changes could fix T271037 indirectly though, but I think the core should be fixed too.
4. I think the deprecation cycles is too tough for me, I just mentioned it once above but get no reply (T273354#6806753).

Some extensions running this hook (not using it) - https://codesearch.wmcloud.org/search/?q=%27EditFilterMergedContent%27&i=nope&files=&excludeFiles=&repos=

Again - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventLogging/+/680607

There is a run today - https://libraryupgrader2.wmcloud.org/logs2/228424

In T182546#6992366, @Jdforrester-WMF wrote:

In T182546#6992361, @Umherirrender wrote:

Do we need the following error? I will upload a patch set with the fixes for core to have a look at

Thanks; it looks a little ugly, but I appreciate it.

20:46:30 FILE: /src/includes/poolcounter/PoolCounterWork.php
20:46:30 ----------------------------------------------------------------------
20:46:30 FOUND 1 ERROR AFFECTING 1 LINE
20:46:30 ----------------------------------------------------------------------
20:46:30  160 | ERROR | There must be a comment when fall-through is
20:46:30      |       | intentional in a non-empty case body
20:46:30      |       | (PSR2.ControlStructures.SwitchDeclaration.TerminatingComment)
20:46:30 ----------------------------------------------------------------------

In general, yes.