Signer loop: exit when shutdown signal received during upgrade loop #934
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.
This PR makes the signer upgrade loop exit in case the shutdown signal is received.
The signer loop wrapper method (
Greenlight::run_forever
) has 2 parts, the upgrade loop (a) and the actual signer loop (b).Inside it, the upgrade loop (a) has the following logic:
scheduler.maybe_upgrade
maybe_upgrade
fails due to a connection issue (error codeCode::Unavailable
when connecting to the scheduler), wait 3 seconds and retrymaybe_upgrade
fails due to any other reason, exit with an errorOk
), then this loop exits and the signer loop (b) startsThe signer loop (b) is already listening and reacting to the shutdown signal.
However, the upgrade loop (a) which is just above it, detailed above, doesn't. This means that, in a situation where the scheduler is not reachable, the upgrade loop (a) would run forever, even if the shutdown signal is received.
This PR wraps
scheduler.maybe_upgrade
in atokio::select
that also listens to the shutdown signal. If received, the entire signer loop is exited.