https://pantsbuild.org/ logo
#development
Title
# development
w

witty-crayon-22786

11/12/2019, 11:54 PM
and that UrlToFetch needs the opposite: completely transparent automatic, etc.
h

hundreds-father-404

11/13/2019, 12:10 AM
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
w

witty-crayon-22786

11/13/2019, 12:38 AM
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
h

hundreds-father-404

11/13/2019, 12:40 AM
Ah. I agree there’s a need to know how many tries it took. What about:
Copy code
result, num_attempts = yield RetryableGet(FallibleExecuteProcessResult, ExecuteProcessRequest, request, max_retries=options.max_retries)
w

witty-crayon-22786

11/13/2019, 12:41 AM
i don't think syntax for this is a good idea.
would still lean toward a sleep intrinsic, roughly.
either that, or baking it into ExecuteProcessRequest