Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What should the behavior be in a dual error & fail close situation? #175

Open
raserva opened this issue Feb 18, 2022 · 2 comments
Open

What should the behavior be in a dual error & fail close situation? #175

raserva opened this issue Feb 18, 2022 · 2 comments
Labels
question Further information is requested
Milestone

Comments

@raserva
Copy link
Contributor

raserva commented Feb 18, 2022

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
@raserva raserva added the question Further information is requested label Feb 18, 2022
@sethvargo
Copy link
Contributor

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).

@raserva
Copy link
Contributor Author

raserva commented Feb 18, 2022

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)

@yolocs yolocs added this to the Backlog milestone Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Development

No branches or pull requests

3 participants