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
{{ message }}
This repository has been archived by the owner on May 3, 2022. It is now read-only.
This is created based on some feedback from our existing users.
The unexpected exception error happens because tchannel captures uncaught exceptions from endpoint handler on the side and then send unexpected error frame back to the client. Right now by default client will retry on unexpected error frame.
However most of the case if the unexpected error happens, probably the user's handler code has some bug causing this. Even we do retry and redirect to other server instance. The instance most likely has the same code deployed. It doesn't make sense to retry on this. It just waste time.
So we may change the protocol to not retry or only retry on certain flag.
The text was updated successfully, but these errors were encountered:
I could agree with adding a "u" flag to opt in for "retry on unexpected error", but it should not default on; retrying on unexpected error seems wrong to me.
This is created based on some feedback from our existing users.
The unexpected exception error happens because tchannel captures uncaught exceptions from endpoint handler on the side and then send unexpected error frame back to the client. Right now by default client will retry on unexpected error frame.
However most of the case if the unexpected error happens, probably the user's handler code has some bug causing this. Even we do retry and redirect to other server instance. The instance most likely has the same code deployed. It doesn't make sense to retry on this. It just waste time.
So we may change the protocol to not retry or only retry on certain flag.
The text was updated successfully, but these errors were encountered: