An API write can be accepted by MediaWiki and still produce no page. The edit returns normally and raises nothing, so a client cannot tell that the write failed without querying the page afterwards.
Observation
Measured on osl.dev.afin-data.de on 2026-09-17, reproduced three times in a controlled comparison.
| Case |
label in jsondata |
Page created |
| A |
absent |
no |
| B |
[{"text": "...", "lang": "en"}] |
yes |
In case A, store_entity returned a page title and a change_id, raised nothing, and listed the page in StoreEntityResult.pages. page.changed was True, so the edit was sent and the server accepted the request. No page exists afterwards.
Entity used
Category:OSW44deaa5b806d41a2a88594f562b110e9 (Person). Its label is optional at the schema level, and the text subproperty is generated by the form editor:
"label": {
"items": {
"properties": {
"text": {
"watch": {
"first_name": "root.first_name",
"middle_name": "root.middle_name",
"surname": "root.surname"
},
"readonly": true,
"dynamic_template": "{{first_name}}{{#each middle_name}} {{.}}{{/each}}{{#if surname}} {{{surname}}}{{/if}}"
}
}
},
"options": {"hidden": true}
}dynamic_template and watch are JSON-Editor form features. They run in the browser only. An API write therefore carries no label unless the caller builds one. label is not in the schema's required list, so nothing rejects the payload on the client side.
A Task cannot reach this state, because label is required in the generated Task model and pydantic rejects the call before any write. Person is exposed because its label is optional.
Ruled out
The mechanism is not in osw-python. A code search of store_entity, store_entity_, handle_upload_object_ and WtPage._edit found no branch that treats label specially. Apart from the label field, the client sends the same request in both cases.
Not yet tested
- whether other categories with an optional
label behave the same way, or only Person
- whether an update of an existing page is rejected the same way, or only a creation
- what the MediaWiki API response body contains in the rejected case
- which component performs the rejection: a hook in Extension:MwJson, a hook in Extension:OpenSemanticLab, an abuse filter, or a SemanticACL rule
Related
Filed here because the reproduction and all the evidence are in osw-python. The cause is server-side, so this issue may need to move to Extension:MwJson or Extension:OpenSemanticLab once the component is identified.
An API write can be accepted by MediaWiki and still produce no page. The edit returns normally and raises nothing, so a client cannot tell that the write failed without querying the page afterwards.
Observation
Measured on osl.dev.afin-data.de on 2026-09-17, reproduced three times in a controlled comparison.
labelin jsondata[{"text": "...", "lang": "en"}]In case A,
store_entityreturned a page title and achange_id, raised nothing, and listed the page inStoreEntityResult.pages.page.changedwasTrue, so the edit was sent and the server accepted the request. No page exists afterwards.Entity used
Category:OSW44deaa5b806d41a2a88594f562b110e9(Person). Itslabelis optional at the schema level, and thetextsubproperty is generated by the form editor:dynamic_templateandwatchare JSON-Editor form features. They run in the browser only. An API write therefore carries nolabelunless the caller builds one.labelis not in the schema'srequiredlist, so nothing rejects the payload on the client side.A
Taskcannot reach this state, becauselabelis required in the generatedTaskmodel and pydantic rejects the call before any write.Personis exposed because itslabelis optional.Ruled out
The mechanism is not in osw-python. A code search of
store_entity,store_entity_,handle_upload_object_andWtPage._editfound no branch that treatslabelspecially. Apart from thelabelfield, the client sends the same request in both cases.Not yet tested
labelbehave the same way, or only PersonRelated
store_entityreported success for a page it never createdStoreEntityParam.verify_write, enabled by default, which detects the missing page and reports it asOSW.PageNotCreatedErrorinStoreEntityResult.failed. It detects the symptom and does not address the cause.Filed here because the reproduction and all the evidence are in osw-python. The cause is server-side, so this issue may need to move to Extension:MwJson or Extension:OpenSemanticLab once the component is identified.