Page MenuHomePhabricator

💥️ Improve error reporting for invalid statement data in REST API (missing field or invalid value)
Closed, ResolvedPublic8 Estimated Story Points

Description

As a Wikidata gadget developer I want to know what part of my input caused an error so that I can adjust my code and make successful edits as intended.

Changes to make to errors on POST, PUT, and PATCH requests.

descriptioncurrent errorintended error
missing required fieldinvalid-statement-datacode: statement-data-missing-field
message: Mandatory field missing in the statement data: {field}
context: { path: FIELD }
invalid data entered in the fieldinvalid-statement-datacode: statement-data-invalid-field
message: Invalid input for {field}
context: { path: FIELD, value: VALUE }
missing required field in the patched statementpatched-statement-invalidcode: patched-statement-missing-field
message: Mandatory field missing in the patched statement: {field}
context: { path: FIELD }
invalid data entered in the field in the patched statementpatched-statement-invalidcode: patched-statement-invalid-field
message: Invalid input for {field} in the patched statement
context: { path: FIELD, value: VALUE }

{field} is to be the easy "field name" that can be provided in the current implementation. Should it be impossible in some cases (e.g. PATCH) to say even that, {field} could potentially be skipped entirely.

Event Timeline

WMDE-leszek renamed this task from Improve error reporting for invalid statement data in REST API to Improve error reporting for invalid statement data in REST API (missing field or invalid value).Dec 2 2022, 9:11 PM
WMDE-leszek updated the task description. (Show Details)
WMDE-leszek set the point value for this task to 8.

Task Breakdown Notes

  • Missing Field Error (@Silvan_WMDE)
    • {field} is the last part of the path
    • Exception will need a field parameter
    • StatementValidator will create a ValidationErrorfrom the Exception (exception type determines error code)
    • use case error responses will map the new ValidationError code to the corresponding response format (see task description)
  • Invalid Field Error (@Jakob_WMDE)
    • {field} is the last part of the path
    • Exception will need a field and a value parameter
    • StatementValidator will create a ValidationErrorfrom the Exception (exception type determines error code)
    • use case error responses will map the new ValidationError code to the corresponding response format (see task description)
  • Consider moving DataValueValidator out of the Validation namespace (@Ollie.Shotton_WMDE)
    • Using the DataValueValidator inside the PropertyValuePairDeserializer creates an interdependency between the two namespaces. This is bad.

Question: @WMDE-leszek, what does value: VALUE mean for the context of missing field errors?

Silvan_WMDE renamed this task from Improve error reporting for invalid statement data in REST API (missing field or invalid value) to 💥️ Improve error reporting for invalid statement data in REST API (missing field or invalid value).Dec 6 2022, 2:49 PM

what does value: VALUE mean for the context of missing field errors?

right, it is a bit silly.
If we know the field is missing, the context should just say which field.

@WMDE-leszek In the description the statement-data-invalid-field error doesn't have a path in the context. Is that intentional? (It could be left out intentionally as long as we only have the field and not a proper path, I guess, but it seems odd for the other error to have it.)

Change 867139 had a related patch set uploaded (by Jakob; author: Jakob):

[mediawiki/extensions/Wikibase@master] REST: Report statement-data-invalid-field errors

https://gerrit.wikimedia.org/r/867139

@WMDE-leszek this is ready for verification apart from one of the error messages is slightly different than the description.

For patched-statement-invalid-field the {field} in the message is wrapped in single quotes:
Invalid input for {field} in the patched statement is actually Invalid input for '{field}' in the patched statement

I prefer the single quotes but it is different to the description and inconsistent with the statement-data-invalid-field message.


Personally, I think we should change all the messages to be more uniform. For example:

  • statement-data-missing-field
    • Mandatory field missing in the statement data: {field} -> Mandatory field '{field}' missing in the statement data
  • statement-data-invalid-field
    • Invalid input for {field} -> Invalid input for field '{field}' or Invalid value for field '{field}'
  • patched-statement-missing-field
    • Mandatory field missing in the patched statement: {field} -> Mandatory field '{field}' missing in the patched statement
  • patched-statement-invalid-field
    • Invalid input for '{field}' in the patched statement -> Invalid value for field '{field}' in the patched statement

But happy to do that as part of a separate task to make error messages more uniform.

Adding single quotes to messages is good, thanks.
Making messages uniform sounds sensible but I'd do it separately as there is some thinking/discussing to do about the exact words to use -- can address it later

Change 880421 had a related patch set uploaded (by Ollie Shotton; author: Ollie Shotton):

[mediawiki/extensions/Wikibase@master] REST: Wrap {field} in single quotes in errors

https://gerrit.wikimedia.org/r/880421

Change 880421 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] REST: Wrap {field} in single quotes in errors

https://gerrit.wikimedia.org/r/880421