Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Having a context object in the run(...) and get(...) methods #371

Open
pandoras-toolbox opened this issue Nov 6, 2023 · 7 comments
Open
Labels

Comments

@pandoras-toolbox
Copy link

A suggestion about the method FailsafeExecutor#run(dev.failsafe.function.CheckedRunnable) and the similar get method.

I think it would be nice if a ExecutionEvent variable would be available like in the method RetryPolicyBuilder#onFailedAttempt(...)

There are some things which you cannot do with the available features of Failsafe if there is no such information in the execution block itself, I mean without workarounds or doing it in an awkward way.

What do you think?

@Tembrel
Copy link
Contributor

Tembrel commented Nov 6, 2023

Doesn't FailsafeExecutor::run(ContextualRunnable<Void>) give you that already?

Failsafe.with(...)
    .run(ctx -> {
        int count = ctx.getExecutionCount();
        ... do stuff with count, maybe throw checked exception ...
    });

As far as I know, the ExecutionEvent types just offer subsets of ExecutionContext information.

@pandoras-toolbox
Copy link
Author

Oh, yes, you are right, I overlooked that method. Thank you!

@pandoras-toolbox
Copy link
Author

But one question, I cannot obtain the duration for the next attempt? I wanted to log that it will wait now for that duration until retrying again.

@jhalterman
Copy link
Member

jhalterman commented Nov 6, 2023

You can configure an OnRetryScheduled event listener on the retry policy, and use event.getDelay(). See:

https://failsafe.dev/retry/#event-listeners
https://failsafe.dev/javadoc/core/dev/failsafe/RetryPolicyBuilder.html#onRetryScheduled-dev.failsafe.event.EventListener-

@pandoras-toolbox
Copy link
Author

Thank you. I cannot do exactly what I wanted in an elegant way because the information is not available in the run(...) block, but nevermind.

@Tembrel
Copy link
Contributor

Tembrel commented Nov 6, 2023

There's no way, elegant or otherwise, to supply the delay before the next execution attempt within the current attempt, because you don't in general know whether the current attempt will be seen as a failure or, if a delay function is used, what delay will be computed. (The delay function can use the result of the failed attempt to determine the delay.)

@pandoras-toolbox
Copy link
Author

Okay, I see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants