Still seen in the logs. Happens a few days a day. Every time the pattern is as follows:

• The referer is a local wiki, such as en.wikipedia.org.
• The request is from a browser, POST to /w/api.php on commons.wikimedia.org.
• The API url looks like /w/api.php?centralauthtoken=******&origin=https%3A%2F%2Fen%2Ewikipedia%2Eorg

It looks like there might be something broken about the upload dialog, or with its consumer in VisualEditor.

It's trying to upload a file, and as part of the upload process, it checks for deleted files that are similar (or something like that), and that check is performed with invalid parameters, and so the entire request gets fataled and rejected. Presumably serving the user an error.

#0 /srv/mediawiki/php-1.31.0-wmf.21/includes/upload/UploadBase.php(822): ArchivedFile->__construct(NULL, integer, string, boolean)

The last parameter here should be a SHA1 hash (a string), but it is apparently false. The invalid value is returned by UploadBase::getTempFileSha1Base36(). I don't know why it would fail, perhaps the file is somehow not being stored?

I think you need to ask someone else than me about why the file backend is failing (and not failing its own failure correctly). I am pretty sure the upload dialog is calling the API correctly.

(Still seen on 1.32-wmf.24)

This happens sometimes on http://www.wiki-brest.net, which I maintain (23 times such a log over 1.5 month) on Media Upload in VisualEditor. According to some tests, the issue could happen iff the file is larger than the authorised file size (2 Mio currently on the mentionned wiki, I will probably increase it).

If this is confirmed, it should be displayed an explanatory instead of this technical error message.

The Editing team does not maintain the upload function.

@MarkTraceur, this looks like a task for your team. If you think that isn't the case, please let us know.

In T187491#5164846, @JTannerWMF wrote:

The Editing team does not maintain the upload function.

From my earlier comment:

@Krinkle wrote:

It looks like there might be something broken about the upload dialog [..] in VisualEditor.

This error is currently only known to affect VisualEditor. I meant to suggest with this, that it might be that VE is using the API incorrectly. This feature is maintained by the editing team, as far as I know.

If investigation shows that the API itself is at fault, please provide a more detailed error report (and ideally steps to reproduce the issue) so that API devs (Core Platform) or Upload backend maintainers (Multimedia) can look further.

Well, throwing an MWException always means the API is at fault. Maybe it's being called in an invalid way and it just omits parameter validation, but that's still a bug.

Thanks, makes sense. Re-triaging accordingly so have maintainers of the Upload functionality and its accompanying API module look at it first. According to Maintainers that is Multimedia indeed. Sorry about the confusion.

In T187491#5180494, @Krinkle wrote:

If investigation shows that the API itself is at fault, please provide a more detailed error report (and ideally steps to reproduce the issue) so that API devs (Core Platform) or Upload backend maintainers (Multimedia) can look further.

See this comment:

In T187491#4540914, @matmarex wrote:

#0 /srv/mediawiki/php-1.31.0-wmf.21/includes/upload/UploadBase.php(822): ArchivedFile->__construct(NULL, integer, string, boolean)

The last parameter here should be a SHA1 hash (a string), but it is apparently false. The invalid value is returned by UploadBase::getTempFileSha1Base36(). I don't know why it would fail, perhaps the file is somehow not being stored?

I think you need to ask someone else than me about why the file backend is failing (and not failing its own failure correctly). I am pretty sure the upload dialog is calling the API correctly.

Here's another sample. This time including the parameters from the POST body (extracted from mwlog:/api.log)

2019-06-25 11:17:49 [XRIC3QpAEMMAABHcAOEAAACI] mw1314 commonswiki 1.34.0-wmf.10 api INFO: API POST *** *** T=58ms action=upload format=json origin=https://en.wikipedia.org errorformat=html errorlang=en errorsuselocal=1 centralauthtoken=[redacted] filename=8)%20***.jpg stash=true filesize=0 offset=0 token=[redacted] formatversion=2

url: POST commons.wikimedia.org /w/api.php?centralauthtoken=***&origin=https%3A%2F%2Fen%2Ewikipedia%2Eorg
referer: https://en.wikipedia.org/
message: MWException: No specifications provided to ArchivedFile constructor.
trace:
#1 /srv/mediawiki/php-1.34.0-wmf.10/includes/upload/UploadBase.php(684): UploadBase->checkAgainstArchiveDupes(boolean)
#2 /srv/mediawiki/php-1.34.0-wmf.10/includes/api/ApiUpload.php(661): UploadBase->checkWarnings()
#3 /srv/mediawiki/php-1.34.0-wmf.10/includes/api/ApiUpload.php(126): ApiUpload->getApiWarnings()
#4 /srv/mediawiki/php-1.34.0-wmf.10/includes/api/ApiUpload.php(104): ApiUpload->getContextResult()
#5 /srv/mediawiki/php-1.34.0-wmf.10/includes/api/ApiMain.php(1595): ApiUpload->execute()
#6 /srv/mediawiki/php-1.34.0-wmf.10/includes/api/ApiMain.php(531): ApiMain->executeAction()
#7 /srv/mediawiki/php-1.34.0-wmf.10/includes/api/ApiMain.php(502): ApiMain->executeActionWithErrorHandling()
#8 /srv/mediawiki/php-1.34.0-wmf.10/api.php(87): ApiMain->execute()

It seems that @Seb35 uncovered the steps to reproduce:

In T187491#4739911, @Seb35 wrote:

This happens sometimes on http://www.wiki-brest.net, which I maintain (23 times such a log over 1.5 month) on Media Upload in VisualEditor. According to some tests, the issue could happen iff the file is larger than the authorised file size (2 Mio currently on the mentionned wiki, I will probably increase it).

If this is confirmed, it should be displayed an explanatory instead of this technical error message.

UploadBase::getTempFileSha1Base36() would fail and return false if $mTempPath is not yet set. This is the boolean that got passed to
ArchivedFile->__construct(NULL, integer, string, boolean),

There supposed to be PHP warning for this case in the underlying function that returns the hash; FSFile::getSha1Base36() but that method is currently suppressing warnings.

In UploadBase::checkWarnings(), where the UploadBase::getTempFileSha1Base36() is called, there seems to be assumption that $mTempPath is already set. But that method has this comment (since 2013 a31d0f8edd16).

/**
 * Check for non fatal problems with the file.
 *
 * This should not assume that mTempPath is set.
 *
 * @param User|null $user Accepted since 1.35
 *
 * @return mixed[] Array of warnings
 */
public function checkWarnings( $user = null ) {
...

The $mTempPath being null also caused T272328. But this possibility is still not documented

Change 683081 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] UploadBase::getSha1Base36FromPath can return false

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

Change 683081 merged by jenkins-bot:

[mediawiki/core@master] UploadBase::getSha1Base36FromPath can return false

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

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