Can @Memoized prevent duplicate writes when a Groovy retry re-invokes a side-effecting method?

Answer

No – @Memoized cannot be relied on to guarantee that a side‑effecting method runs only once when a hand‑rolled retry loop re‑invokes it. It will prevent duplicate execution only when the first invocation completes normally and the method is called with exactly the same arguments on every retry attempt. If the first call throws an exception, or if any argument changes between attempts, the method will be re‑executed on each retry.

Confirmed facts from Groovy’s @Memoized transformation

• The annotation caches the return value **only after a method returns normally**. If the method throws an exception, no cache entry is created and the next call with the same arguments will execute the method body again.
• The cache key is based solely on the method’s argument values; it does not distinguish between pure and side‑effecting methods.
• This behavior is the same across Groovy 2.x‑4.x and is unaffected by @CompileStatic or the chosen compile mode.

Likely explanation for the retry scenario

When a retry loop surrounds a @Memoized method:

1. First attempt succeeds – the method runs, performs its write, returns a value, and that value is stored in the cache.
2. Subsequent retries with identical arguments – the cache lookup returns the stored value, the method body is skipped, and no additional write occurs.
3. First attempt throws – nothing is cached, so the retry invokes the method again, causing the write to repeat.
4. Any argument differs between attempts – the cache miss forces a re‑execution, again repeating the write.

Steps to verify the behavior in your code

1. Create a @Memoized method that increments a static counter and returns a value.
2. Wrap a call to that method in a try/catch loop that retries on a specific exception.
3. Run the test with two scenarios: (a) the first call succeeds, (b) the first call throws and the second succeeds.
4. Observe the counter: it should increment only once in scenario (a) and twice in scenario (b).
5. Optionally, modify the retry loop to pass a different argument (e.g., an attempt counter) on each iteration and confirm that the counter increments on every attempt.

What you need to know to decide

The only missing detail that changes the recommendation is whether your retry logic passes **exactly the same arguments** on each attempt. If any argument (such as a retry counter, timestamp, or mutable payload) varies, @Memoized will not deduplicate the write, and you must add an explicit idempotency guard (e.g., a flag, a database check, or a deduplication token).