Reduce 5xx spam #496
Reduce 5xx spam #496
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?
| 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?
3 participants
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.