Page MenuHomePhabricator

Content serialization failed: Failed to decode as application/json (when parsing edit summary via API)
Open, MediumPublic

Description

The API request

  • action: parse
  • summary: based on wikidata [[d:P:P176|manufacturer]]
  • prop: empty

works on enwiki (1.36.0-wmf.37): https://en.wikipedia.org/w/api.php?action=parse&format=json&summary=based%20on%20wikidata%20%5B%5Bd%3AP%3AP176%7Cmanufacturer%5D%5D&prop=

{
  "parse": {
    "title": "API",
    "pageid": 27697009,
    "parsedsummary": {
      "*": "based on wikidata <a href=\"https://www.wikidata.org/wiki/P:P176\" class=\"extiw\" title=\"d:P:P176\">manufacturer</a>"
    }
  }
}

but fails on wikidatawiki (1.36.0-wmf.38): https://www.wikidata.org/w/api.php?action=parse&format=json&summary=based%20on%20wikidata%20%5B%5Bd%3AP%3AP176%7Cmanufacturer%5D%5D&prop=

{
  "error": {
    "code": "parseerror",
    "info": "Content serialization failed: Failed to decode as application/json",
    "*": "See https://www.wikidata.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at &lt;https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce&gt; for notice of API deprecations and breaking changes."
  },
  "servedby": "mw1363"
}

This broke the QuickCategories tool until I deployed a workaround.

The error message makes no sense to me, so I’m assuming this is a bug, not an intentional API change.

Event Timeline

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

dduvall triaged this task as High priority.Apr 7 2021, 8:45 PM
dduvall added a subscriber: dduvall.

Not quite UBN for now and I haven't rolled back on account of it, but this needs more eyeballs.

dduvall raised the priority of this task from High to Unbreak Now!.Apr 7 2021, 8:59 PM
dduvall added a project: Platform Engineering.

Marking UBN as I plan on blocking until this is resolved.

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.

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.

dduvall lowered the priority of this task from Unbreak Now! to Medium.Apr 7 2021, 11:03 PM
Krinkle moved this task from Mar 2021 to Apr 2021 on the Wikimedia-production-error board.
Krinkle added a subscriber: Krinkle.

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)

Addshore added a subscriber: Addshore.

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.

Krinkle renamed this task from Error on wmf.38 when parsing edit summary via API: Content serialization failed: Failed to decode as application/json to Content serialization failed: Failed to decode as application/json (when parsing edit summary via API).Oct 11 2021, 2:43 AM

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

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.