Conversation
| Status: reason, | ||
| } | ||
| result = psrpc.NewErrorf(psrpc.Canceled, "call transfer failed: %w", st) | ||
| psrpcErrCode := psrpc.UpstreamServerError |
There was a problem hiding this comment.
Going over twirp, this will still produce a bad error, due to Twirp not having the appropriate response codes to convert this to. However, data indicates the vast majority of errors are not 5XX errors and are going to be UpstreamClientError. which would convert to twirp.InvalidArgument.
There was a problem hiding this comment.
this isn't related to Twirp, but our error code mapping in psrpc? why don't we just map it to the right thing there?
There was a problem hiding this comment.
This completely ignores the existing mapping to gRPC/PSRPC/Twirp error codes that we have. Maybe we should update the mapping there instead?
There was a problem hiding this comment.
If you refer to the code here , I suspect we never reach the unwrap point since if errors.As(err, &e) { succeeds, due to us returning a psrpc.Error.
If I read this right SIPStatus.GRPCStatus() gets called when we don't return a psrpc error, but a SIPStatus instead.
davidzhao
left a comment
There was a problem hiding this comment.
do we also handle other common incorrect error mapping? for example, CreateSIPParticipant is also throwing some of these errors
| Status: reason, | ||
| } | ||
| result = psrpc.NewErrorf(psrpc.Canceled, "call transfer failed: %w", st) | ||
| psrpcErrCode := psrpc.UpstreamServerError |
There was a problem hiding this comment.
this isn't related to Twirp, but our error code mapping in psrpc? why don't we just map it to the right thing there?
Today we return
psrpc.Canceled, which then gets translated to HTTP code 500. This can be quite problematic when we get return codes like:480 Temporarily Unavailable,603 Decline,486 Busy Here,404 Not Found. These are either user errors, outright rejections, or numbers incapable of handling two simultaneous calls.This change will get us to emit
UpstreamServerErrorandUpstreamClientErroras responses, that would translate to HTTP codes 502 and 424 respectively, correctly identifying failures in resources upstream of the sip server.