i am still under the impression that the easier thing to implement is generic retry and then extending it to have different behaviors, controllable by the engine which can schedule it smartly and/or do other funky things with it. i feel like that’s the kind of execution strategy we want to abstract away, using the engine. we can then expose

UrlToFetch

strictly as a primitive and just use wrapper rulesets elsewhere e.g. for an

IdempotentUrlToFetch

, which would perform the transparent retry we want using RetryableGet. we can then effectively make use of that generic tool in RetryableGet to develop (in python, not rust) other wrappers that perform the desired behavior on top of other primitives like

UrlToFetch

. i feel like starting with an approach that specifically only works for one use case (test xor url fetch) that’s not intended to generalize is extra work that we don’t necessarily need to do.