Invalid language codes in the request body aren't values, they're the keys in labels/descriptions/aliases. The message would say "Invalid value at '/item/labels/bad-language-code'" which doesn't fit.

Since the upstream change was merged an published, this now requires:

• bumping the version to the latest one in composer.json
• in repo/rest-api/src/Application/UseCases/PatchJson.php, change the UseCaseError accordingly
• adjust e2e tests

Upstream change was merged very quickly! \o/

One related bit of surprising behavior I've just encountered is that the API now responds with failureCode: 'missingparam' if a required string field is defined but empty (""). Not sure if this was intentional, but I'm pretty sure empty strings weren't rejected by the legacy JsonBodyValidator mechanism.

Task breakdown notes:

• adjust the request validating deserializers accordingly
• adjust the examples in the spec

Task breakdown notes:

• respond with the new errors for _fields (item), _fields (property)
  • adjust the corresponding deserializing request validators to throw the new kinds of UseCaseErrors
  • adjust the examples in the spec
• respond with the new error for property (statements list)
  • adjust the examples in the spec
  • this currently reuses the same validator as property ID path parameters but now needs a separate validator since the error is different

Task breakdown notes:

• create one interface for each labels, descriptions and aliases, but reuse the same (existing) implementation
• create one service wiring entry for each
• use the new validators in all deserializers
• use the new validators in all RequestValidatingDeserializers
  • split LanguageCodeRequest into three accordingly
• this may not be enabled in CI yet so creating an e2e test (that passes in CI) might not be straightforward. Talk to the WD team :)
• setting name: tmpEnableMulLanguageCode
• getDefaultTermsLanguages returns mul if it is configured which is confusing since it's not valid for all kinds of terms. It would be nice to have this cleaned up in the rest of Wikibase as well. We should talk to the WD team about it or at least make sure there is a ticket.

We looked at some requests through XHGui and are now convinced that the performance impact is negligible and doesn't require more elaborate testing. We stumbled upon a worst case scenario while looking at a page on Wikivoyage accessing item data (profile) in which all property info was requested from the database, which took 240ms for PropertyInfoTable::getAllPropertyInfo with an inclusive wall time of 274ms for all 3162 calls to CachingPropertyInfoLookup::getPropertyInfo. Subsequent requests to the same page took ~20ms for all calls to getPropertyInfo. Given that even expensive wbcheckconstraints requests aren't going to exceed this dramatically (13604 calls to needsDataTypeLookup here, only some of which will actually result in lookups), we feel confident that this is fast enough.

Creating an entity schema statement on an item worked fine for me.

Here are the corresponding action API responses for four of the cases:

I think this should probably be prioritized higher. After a software update, my mwcli broke pretty spectacularly similar to the error described here and here. For now I managed to fix the problem by uninstalling docker-compose, installing the docker-compose-plugin and aliasing docker compose to docker-compose. I now get a bunch of warnings saying .config/mwcli/mwdd/default/[service].yml: version is obsolete but at least it's working again.

I tested this with a simple e2e test that does the following: 1. create item, 2. create property with data type item, 3. create statement on item using the newly created property, 4. get the new statement. This all worked fine out of the box, so I added an artificial delay to the DataUpdater that inserts the property info which is needed for the data type lookup. Interestingly the statement creation never failed, because it uses the data type lookup that has a fallback on top of the property info based lookup. In step 4 the statement value shows the UnDeserializableValue serialization while the data type lookup fails.

Thanks for spotting this issue! We had wbformatvalue on our radar as well. Getting it to work as long as datatype or property are provided should be straightforward. I'll make a patch!

In T360603#9704577, @Physikerwelt wrote:

Maybe this also applies to extension MathSearch?