Mentioned in SAL (#wikimedia-cloud) [2021-04-07T20:00:59Z] <wm-bot> <lucaswerkmeister> deployed c3c66caf96 (work around T279585)

I think the error message means that action=parse is trying to use the text parameter (which would normally contain the wikitext to parse), except that you did not provide it, and also it's using the content model application/json instead of text/x-wiki because that's the default content model of the main namespace on Wikidata (and the default title when not provided is "API", which is in main namespace).

I have not looked at any of the code though, just guessing. But my guess is that this will only affect Wikidata, and should not block the train from rolling out to other wikis (but it may be a blocker for Wikidata?). The query also works on mediawiki.org.

In T279585#6981834, @matmarex wrote:

I have not looked at any of the code though, just guessing. But my guess is that this will only affect Wikidata, and should not block the train from rolling out to other wikis (but it may be a blocker for Wikidata?). The query also works on mediawiki.org.

I appreciate the guessing! It's much more than I had to go on previously. Added Wikidata folks to get thoughts on severity there.

Hm, thanks. If I add contentmodel text/x-wiki, I get an internal error instead: https://www.wikidata.org/w/api.php?action=parse&format=json&summary=summary&prop=&contentformat=text%2Fx-wiki

{
    "error": {
        "code": "internal_api_error_InvalidArgumentException",
        "info": "[0009a4bd-06fa-48c2-a925-b7875275e3d3] Caught exception of type InvalidArgumentException",
        "errorclass": "InvalidArgumentException"
    },
    "servedby": "mw1346"
}

I guess that must be because of the missing text. If I add text as empty, then it works. (But there are also more warnings, because it’s still not a proper content parse request – except I’m not interested in parsing content in the first place, only the edit summary. But apparently something changed that makes parsing the summary alone more difficult?)

Anyways – if this is indeed exclusive to Wikidata (and Test Wikidata, I guess – do we have other wikis where the main namespace is not wikitext?), then this probably doesn’t need to block the train.

Still tracking as prod error, I think?

Mentioned in SAL (#wikimedia-cloud) [2021-04-09T18:16:40Z] <wm-bot> <lucaswerkmeister> deployed 24f6e19113 (better workaround for T279585)

I think the error message means that action=parse is trying to use the text parameter (which would normally contain the wikitext to parse), except that you did not provide it, and also it's using the content model application/json instead of text/x-wiki because that's the default content model of the main namespace on Wikidata (and the default title when not provided is "API", which is in main namespace).

Summary probably should always use the wikitext content model for parsing as a default?
Rather than falling back to a contentmodel, which doesn't really relate to summaries all that much.

Looking at ApiParse.php UI can't see exactly where the decision happens on what content model to use for summary parsing, but I think this is perhaps a core bug / something for the core platform team.

The summary is parsed as a summary, that’s not the problem as far as I understand. But it’s now trying to parse page content even when neither text nor page have been specified, and failing if the empty string isn’t valid content.

In T279585#6982103, @LucasWerkmeister wrote:

Hm, thanks. If I add contentmodel text/x-wiki, I get an internal error instead: https://www.wikidata.org/w/api.php?action=parse&format=json&summary=summary&prop=&contentformat=text%2Fx-wiki

{
    "error": {
        "code": "internal_api_error_InvalidArgumentException",
        "info": "[0009a4bd-06fa-48c2-a925-b7875275e3d3] Caught exception of type InvalidArgumentException",
        "errorclass": "InvalidArgumentException"
    },
    "servedby": "mw1346"
}

I guess that must be because of the missing text. If I add text as empty, then it works. (But there are also more warnings, because it’s still not a proper content parse request – except I’m not interested in parsing content in the first place, only the edit summary. But apparently something changed that makes parsing the summary alone more difficult?)

Anyways – if this is indeed exclusive to Wikidata (and Test Wikidata, I guess – do we have other wikis where the main namespace is not wikitext?), then this probably doesn’t need to block the train.

That was fixed as part of T206253

In T279585#6992153, @LucasWerkmeister wrote:

The summary is parsed as a summary, that’s not the problem as far as I understand. But it’s now trying to parse page content even when neither text nor page have been specified, and failing if the empty string isn’t valid content.

Documentation may be not clear:

https://www.wikidata.org/w/api.php?modules=parse

Parameters:
title
Title of page the text belongs to. If omitted, contentmodel must be specified, and API will be used as the title.
contentmodel
Content model of the input text. If omitted, title must be specified, and default will be the model of the specified title.

But the error seems the expected behaviour (title API is in main namespace and that is wikibase-item content model), even when only the summary should be parsed (because action=parse want to give a title to CommentFormatter - correct fragment linking)

https://www.wikidata.org/w/api.php?action=parse&format=json&summary=[[%23Link]]&title=Wikidata:Main_Page&prop=

Just give the correct title the summary is used for or provide a better default with wikitext (like the main page from siteinfo).

I would say that this task should be declined and if something is missing, like parse a summary without a title, that sounds like a new feature. But the task with the current description sounds unfixable without many breaking changes in api parse module.