Page MenuHomePhabricator

Warning: Failed to find "wikibasemediainfo-statements-unsupported-property-type-content" in message cache
Closed, InvalidPublicPRODUCTION ERROR

Description

Error

Request URL: GET commonswiki /w/load.php?debug=false&lang=ja&modules= … wikibase.api.RepoApi%7Cwikibase.entityPage.entityLoaded%7Cwikibase.mediainfo.filePageDisplay&skin=vector&version= …
Request ID: XQtofQpAAD8AAIyx3dMAAAAN

event
channel: resourceloader
level: WARNING
normalised: Failed to find {messageKey} ({lang})
message
Failed to find wikibasemediainfo-statements-unsupported-property-type-content

Impact

Unknown.

Notes

See Codeseach query.

Specified in the module definition and referenced in the JS code with mw.message( …  ).parse(). But, the message is not defined in the source language.

Event Timeline

@Krinkle as far as I can tell, the message does exist in other languages, but not ja - does the RL code not do proper language fallback for some reason? Or is this purely a cache issue? As far as I can tell, the JS code and extension.json look pretty much the same as every other use of messages in the extension, and in other extensions I've worked on. Just trying to get an idea of what we need to do differently, if anything, in the WBMI code.

@MarkTraceur For a message key to be valid, it must exist in the source language (en) and preferably documented as well. This messages only has a few unconnected translations, but no source. This usually indicates that a message was removed but that localisation sync hasn't removed the translations yet.

If a message is optional for display, it should have a default of "" or "-", but still exist (en) and documented (qqq).

To answer your question: ResourceLoader uses the MessageCache from MediaWIki as-is. So if you can visit MediaWik:<key>/<lang> as a page on the wiki and se the message, then ResourceLoader will as well.

I see the message key in WikibaseMediaInfo en.json now, and appears to have been for at least several weeks. Not sure what I saw, but I recall it being missing somehow. Which is indeed the only scenario in which this error could happen in production.

Maybe something went wrong during deployment last week. Anyhow, I don't see it anymore now. And commons shows the message key now without any issue.

Krinkle moved this task from Untriaged to Resolved on the Wikimedia-production-error board.

This RL caching bug has hit us during a few deploys over the past couple of months. It sucks, yes. :-( Generally I "fix" it by creating the message locally, and then deleting it.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:06 PM