oh well we can already do retries like you describe by just requesting

FallibleExecuteProcessResult

instead

but if a persistent connection is required, i would probably do what i'm doing with my bloop compile work right now and just have my rule loop over some input stream

we can absolutely implement retries on the engine side though -- i'm thinking that's something we could do with another type of

CommandRunner

(cc @early-needle-54791), although i don't know if that's the right level of abstraction to do it at

would depend on whether we care about things like the output from each failed attempt, or whether we just want to send back the result of the first successful request

i think "flaky process execution" or "flaky url fetch" sounds like something we might want to be able to represent in the engine in a generic way (e.g., off the top of my head, adding an intrinsic which accepts a dataclass containing a process execution request + "flakiness metadata"), which might then be applicable to the ci pytest runner

i think we can do all of that in python v2 rules though

and if we can, it's better to do that

i can also check

but that's so easy

oh

you also mean in the in-memory node memoization

additionally, in the persistent process execution cache, we persist failed executions

which might be more correct, but it's not the behavior i think i personally want

i think

ok, well, for a console rule or something that is intended to execute a process, we can add something extra to invalidate the process request upon failure

one thing you could do might be:

@rule(A, [...]):
def f(...):
  def make_uncached_exe_req(index):
    return ExecuteProcessRequest(
      argv=(...),
      env={'_CACHE_KEY_ENV_VAR': str(index)},
      ...)
  for i in range(0, 10):
    res = yield Get(FallibleExecuteProcessResult, ExecuteProcessRequest, make_uncached_exe_req(i))
    # do something with `res`...

i believe that should avoid having failed executions being cached