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
Right now, our fail close behavior is to return an error rather than the server's response if they have specified the audit logger should fail close. We have also added behavior to audit log server errors when they occur. What should we do if both the server has an error, and the audit logger has an error when fail close is enabled?
Should we:
Return the original server error, so that the client potentially can make informed decisions about retries or get information on why their call failed
Return an audit logging error, and fail close without returning the server's error, or wrapped in our own error
The text was updated successfully, but these errors were encountered:
I'm hesitant to leak server-specific errors to the client. Ideally the server should have a list of well-known response codes upon which the client should always retry (including 500s).
Sorry - so that is more clear. our expectation is that we're an interceptor here, so we're not returning a server-specific error that they weren't sending before. So, in this case, likely the server would raise some error code (say some 500) in a StatusRuntimeException, and either we return that StatusRuntimeException/500 as is, or raise our own (which is what we do when we fail close)
Right now, our fail close behavior is to return an error rather than the server's response if they have specified the audit logger should fail close. We have also added behavior to audit log server errors when they occur. What should we do if both the server has an error, and the audit logger has an error when fail close is enabled?
Should we:
The text was updated successfully, but these errors were encountered: