You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is a message: STRING|null field in the response object of the engine_executePayload method. This field is supposed to be used in the case when the payload is invalid to provide additional information on what exactly has failed. This should improve CL client logs readability as it will give an idea of what went wrong during the execution without the strong need of looking into EL client logs.
@MariusVanDerWijden pointed out that the message field is confusing as it doesn't correspond to the regular JSON-RPC error format. There is a couple of options:
Replace message with validationError: null|{code: errorCode, message: errorMessage} field
Rename message to validationError and doesn't render the code
IMO, the first option does make sense if there is a list of messages and codes corresponding to errors occurred during validation and execution of a payload. If there is no such list it probably doesn't worth spending a time on standardising these errors and then adjusting clients to adhere to this standard, the option 2 could work good as long as there is a meaningful message put in the validationError field, event though the messages vary from one EL client to another.
The text was updated successfully, but these errors were encountered:
Not a strong opinion, but I prefer option number one.
If a consensus client has to react in a standard way to a given error type in the future, it will be better to have error codes.
Not a strong opinion, but I prefer option number one.
If a consensus client has to react in a standard way to a given error type in the future, it will be better to have error codes.
Ended up with option number two. Because if we'd want a standard reaction of CL client it'd require standardising error codes which sounds overcomplicated in the context of UX improvement that was the original intention behind bubbling this error message.
Currently there is a
message: STRING|null
field in the response object of theengine_executePayload
method. This field is supposed to be used in the case when the payload is invalid to provide additional information on what exactly has failed. This should improve CL client logs readability as it will give an idea of what went wrong during the execution without the strong need of looking into EL client logs.@MariusVanDerWijden pointed out that the
message
field is confusing as it doesn't correspond to the regular JSON-RPC error format. There is a couple of options:message
withvalidationError: null|{code: errorCode, message: errorMessage}
fieldmessage
tovalidationError
and doesn't render the codeIMO, the first option does make sense if there is a list of messages and codes corresponding to errors occurred during validation and execution of a payload. If there is no such list it probably doesn't worth spending a time on standardising these errors and then adjusting clients to adhere to this standard, the option 2 could work good as long as there is a meaningful message put in the
validationError
field, event though the messages vary from one EL client to another.The text was updated successfully, but these errors were encountered: