Question: defining strict error schemas

[qweeze]

We use errors[].data field to pass detailed errors to client, like so:

{
    "jsonrpc": "2.0",
    "error": {
        "code": 6000,
        "message": "Invalid parameters",
        "data": {
            "errors": [
                {
                    "code":"wrong_code",
                    "path": "sms_code",
                    "message": "Verification code mismatch"
                },
                {
                    "code":"wrong_payee_id",
                    "path": "payments[2].payee",
                    "message": "Invalid payee ID"
                }
            ]
        }
    },
    "id": 42
}

We'd like to be able to specify JSON schemas for these (inner) errors, without violating the OpenRPC spec or breaking backwards compatibility. We've come up with the following approach:

• put the JSON schemas of inner errors in the errors[].data attribute of an OpenRPC schema
• add a custom global-scoped flag, i.e. x-error-data-schema: bool which indicates should the data property of errors be treated as a schema or not. If the flag is set, all the related tools (validators, code generators, documentation viewers) should assume that error responses' data attribute is constrained with these schemas and act accordingly.

Alternatively, the spec itself could probably be updated to support defining specific schemas for errors. I might be wrong but it feels like a nice-to-have feature that could come in handy not only for our use case. As for implementation, adding a separate dedicated attribute like errors[].data-schema should suffice.

To sum up, my questions are:

1. Is our approach with adding x-error-data-schema a legit and intended/idiomatic way of expanding the spec?
2. Should we propose a spec update?

[github-actions]

Welcome to OpenRPC! Thank you for taking the time to create an issue. Please review the guidelines