This repository has been archived by the owner on Apr 15, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 37
Distinguish between permanent and retryable failures in refreshing #92
Comments
jaapterwoerds
changed the title
Distinguish between permanent and retryable failures in
Distinguish between permanent and retryable failures in refreshing
Mar 25, 2016
There should be a retry limit. Could you please confirm that this doesn't work during refreshing? |
The retry limit is in place and works as expected. |
Thanks for checking. I can close this then. |
@hseeberger while indeed the retry limit works, it would be nice to 'fail fast' instead of retrying in case of known-to-be-unrecoverable errors. |
@hseeberger @raboof The intent of this issue was indeed to be able to signal to 'fail fast' from the coordinator implementations. |
The workings of the state machine are already very complex. Adding various ways of failure would increase complexity, hence I'm a bit on the fence here. Could you please suggest a complete (not only Consul) specification of unrecoverable errors and ways to test the new behavior? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In some case the refresh fails with a permanent error. Instead of going in the retry logic, we could directly stop the ConstructrMachine FSM.
As an example: in the consul-coordinator implementation renewing the session can fail with an unrecoverable error in which retrying is useless. See also: Tecsisa/constructr-consul#5.
The text was updated successfully, but these errors were encountered: