Error serialization logic is faulty #51
Description
Errors are "serialized" using the serializeError function, and this function has considerable issues. We use the internal utility isValidCode which only returns true if this package has a message for that code in its enums. This sucks, because technically any valid integer code is valid. I don't know what I was thinking when I implemented this.
The error serialization should continue to optionally include the stack property, but it should permit any error object (and especially, error code) that is valid per the JSON-RPC 2.0 specification, i.e. any integer number. Only if the original error object does not conform to the following interface should we modify it and replace it with a -32603 error:
type JsonRpcError = {
code: number, // specifically, any safe integer
message: string,
data?: Json,
stack?: string, // non-standard, but on occasion useful
}If a value passed to serializeError violates this interface in any way, we should create a new JSON-RPC error as follows, where data.originalError is the original error value if it's valid JSON:
{
code: -32603,
message: 'Invalid internal error. See "data.originalError" for original value. Please report this bug.',
data: { originalError }
}See #48 and the following screenshot for examples of how the current logic mangles errors:
