E2E: Consistent and configurable timeouts #797
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sample implementation for #487.
Timeout is now handled by the scheduler instead of happening directly in the service notifier.
Timeouts can be declared as a number of failed checks or as the number of seconds passed, both only affecting the startup. At least one check has to be done because otherwise the timeout would be triggered even in a perfectly working condition. It is not possible to disable timeouts for now, but could be addressed relatively easily if needed.
Timeouts are always called right after a check, even when declared as a time span, because the state wouldn't change anyway and it makes it easier to schedule the timeout exactly. If the check happens every 5s and the timeout is set at 10, it will always be called after exactly two checks. This would not be guaranteed by a simple
Process.send_after(self(), :timeout, timeout_s)
, as check calls may take a bit more milliseconds than an exactcheck_interval_ms
.If declaring the timeout at the exact second it was requested, we must check that both the declared amount of seconds has passed and
div(timeout_s, check_interval_s)
checks have been made, but as I said I have only implemented the required number of checks for now.As a side note, now consequent checks are scheduled immediately instead of waiting for the previous check to end (5cdb1ff). This might be outside the scope of this pr but I'll leave it here for now, as I believe fixing the scheduling is the scope of this pr.