Skip to content
This repository has been archived by the owner on Apr 15, 2018. It is now read-only.

Distinguish between permanent and retryable failures in refreshing #92

Closed
jaapterwoerds opened this issue Mar 25, 2016 · 6 comments
Closed

Comments

@jaapterwoerds
Copy link

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.

@jaapterwoerds jaapterwoerds changed the title Distinguish between permanent and retryable failures in Distinguish between permanent and retryable failures in refreshing Mar 25, 2016
@hseeberger
Copy link
Owner

There should be a retry limit. Could you please confirm that this doesn't work during refreshing?

@jaapterwoerds
Copy link
Author

The retry limit is in place and works as expected.

@hseeberger
Copy link
Owner

Thanks for checking. I can close this then.

@raboof
Copy link
Contributor

raboof commented Apr 5, 2016

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

@jaapterwoerds
Copy link
Author

@hseeberger @raboof The intent of this issue was indeed to be able to signal to 'fail fast' from the coordinator implementations.

@hseeberger
Copy link
Owner

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.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants