Mavis
1d5b6a9f93
The kRPC proto defines error on Response and ProcedureResult as
type Error (a sub-message), not raw bytes. The schema already
declared it that way, so protobufjs was decoding the error as
a nested Error object automatically.
But our client code was treating response.error as if it were
a Uint8Array of raw bytes (matching the wrong type annotation
we had earlier), and we were trying to decode those bytes as
a second Error message. That double-decode was the source of
the "RPC error: .:" with stray substitute character and the
"index out of range" errors when the bytes happened to look
like other protobuf structures.
Fix: use the auto-decoded error object directly. response.error
is now { service, name, description, stackTrace } when set,
and we just read those fields.
This should also let the actual response values decode correctly,
since we were previously mangling the error path.
22 lines
961 B
Plaintext
22 lines
961 B
Plaintext
fix: use sub-message decoding for Error fields (not raw bytes)
|
|
|
|
The kRPC proto defines error on Response and ProcedureResult as
|
|
type Error (a sub-message), not raw bytes. The schema already
|
|
declared it that way, so protobufjs was decoding the error as
|
|
a nested Error object automatically.
|
|
|
|
But our client code was treating response.error as if it were
|
|
a Uint8Array of raw bytes (matching the wrong type annotation
|
|
we had earlier), and we were trying to decode those bytes as
|
|
a second Error message. That double-decode was the source of
|
|
the "RPC error: .:" with stray substitute character and the
|
|
"index out of range" errors when the bytes happened to look
|
|
like other protobuf structures.
|
|
|
|
Fix: use the auto-decoded error object directly. response.error
|
|
is now { service, name, description, stackTrace } when set,
|
|
and we just read those fields.
|
|
|
|
This should also let the actual response values decode correctly,
|
|
since we were previously mangling the error path.
|