and that UrlToFetch needs the opposite: completely transparent automatic, etc.

Agreed. Both use cases are different: we want

test

to have retries completely exposed and parametrized to the user, whereas

UrlToFetch

should probably be automatic Either way, we need a mechanism for them to both have the same retry behavior: if the rule fails, retry up to n times We can add the custom logic on top of this mechanism, like configuring the number of retries or presenting it to the user differently. This would all build off of the underlying mechanism

i was thinking more from a metadata consumption perspective: a consuming @rule would want to know how many attempts something took in the

test

case

Ah. I agree there’s a need to know how many tries it took. What about:

result, num_attempts = yield RetryableGet(FallibleExecuteProcessResult, ExecuteProcessRequest, request, max_retries=options.max_retries)

i don't think syntax for this is a good idea.