Skip to content

Conversation

@johnrichardrinehart
Copy link

Description

The idea introduced, here, is to add a "memory" parameter for the retry policy. If a long-running retryable operation (like chainsync) fails sporadically then the downstream oura user may not actually want the retry counter to increment. By default, the memory should be longer than the longest possible delay. If this isn't done then max_retries will never be encountered and retry_operation will never return. This case (never returning) may be desirable in some cases (like for a daemon application). But, it should not be the default case.

The idea introduced, here, is to add a "memory" parameter for the retry
policy. If a long-running retryable operation (like chainsync) fails
sporadically then the downstream oura user may not actually want the
retry counter to increment. By default, the memory should be longer than
the longest possible delay. If this isn't done then max_retries will
never be encountered and retry_operation will never return. This case
(never returning) may be desirable in some cases (like for a daemon
application). But, it should not be the default case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

No open projects
Status: No status

Development

Successfully merging this pull request may close these issues.

1 participant