`wait_for_condition` and `run_in_child_context` persist a terminal FAIL checkpoint for a retryable InvocationError

[ayushiahjolia]

Problem

When an InvocationError escapes a wait_for_condition check (or run_in_child_context body), execute() persists a FAIL checkpoint (is_sync=True) and then re-raises to trigger a Lambda retry. But the committed FAIL makes the retry useless: on replay, check_result_status() sees is_failed() → raise_callable_error() → CallableRuntimeError → handler returns FAILED. The check/body never re-runs, and the error type silently changes from InvocationError to CallableRuntimeError.

Contrast

step handles this correctly: a retryable error goes through retry_handler, which writes a RETRY checkpoint (non-terminal, re-executes) and only writes FAIL once retries are exhausted.

def check(state, ctx):
    raise InvocationError("transient failure")
context.wait_for_condition(check=check, config=WaitForConditionConfig(...))

First run: FAIL persisted, InvocationError bubbles, Lambda retries.
Retry: short-circuits to CallableRuntimeError, check never re-runs.

Proposed fix

Re-raise InvocationError before writing the FAIL checkpoint in both wait_for_condition.execute() and child.execute() (including is_virtual). Keep writing FAIL for non-retryable errors (e.g. BotoClientError with is_retryable() == False).

[yaythomas]

Two nits/clarifications on the proposal: the is_virtual mention a no-op since the virtual path already skips the FAIL checkpoint, and the gate must be isinstance(e, InvocationError) and e.is_retryable() so non-retryable subclasses like BotoClientError still write FAIL.

One side effect to note is that the attempt counter will not increment across these invocation retries, which matches JS semantics.