[Bug]: Virtual child contexts exit replay early and omit resumed operation notifications #889

Expected Behavior

Entering run_in_child_context(..., config=ChildConfig(is_virtual=True)) during replay must not treat the absence of the virtual container's checkpoint as evidence of new work. A virtual container intentionally has no checkpoint, while its inner operations can have persisted history.

When the next inner operation is an existing successful wait reported as updated since the previous invocation, the child should retain replay status long enough to consume that history and deliver the normal operation-update notification. It can then transition to NEW at the actual replay boundary.

Actual Behavior

The core SDK changes the parent from REPLAY to NEW before creating the virtual child. The child inherits NEW, so its existing wait bypasses the replay/update notification gate.

A core-only comparison, with the same completed wait in the supplied state, produces:

{'virtual': False, 'child_enters_replay': True, 'wait_update_hooks': ['virtual-wait'], 'result': 'ok'}
{'virtual': True, 'child_enters_replay': False, 'wait_update_hooks': [], 'result': 'ok'}

Both calls return the stored successful wait outcome. The demonstrated defect is replay-state classification and the omitted notification; this reproduction does not demonstrate a failed wait or repeated business side effects. An observable consequence is missing terminal wait telemetry in Execution view when a virtual child suspends and resumes. Other consumers of replay status, including replay-aware logging, may also be affected, but that broader impact has not been validated here.

Steps to Reproduce

The motivating workflow is a virtual child running step -> durable wait (5 s) -> step, with the wait completing between invocations. On resume, the virtual container has no checkpoint by design, but its inner operations do.

The following focused reproduction isolates the core boundary without AWS credentials, an OTel plugin, or an exporter. It uses the real DurableContext.run_in_child_context and wait implementations, with a mocked execution-state boundary that supplies a successful updated wait. The ordinary-child control has a STARTED container checkpoint; the virtual child correctly has none.

Run from the Python SDK repository root at the tested revision:

PYTHONDONTWRITEBYTECODE=1 hatch run dev-otel:python - <<'PYTHON'
from datetime import UTC, datetime
from unittest.mock import Mock
from aws_durable_execution_sdk_python.context import DurableContext, ExecutionContext
from aws_durable_execution_sdk_python.config import Duration, ChildConfig
from aws_durable_execution_sdk_python.state import ReplayStatus, CheckpointedResult
from aws_durable_execution_sdk_python.lambda_service import (
    Operation, OperationType, OperationStatus, OperationSubType,
)

for virtual in (False, True):
    state = Mock()
    state.wrap_user_function.side_effect = lambda func, *args, **kwargs: func
    state.durable_execution_arn = 'test-arn'
    parent = DurableContext(
        state, ExecutionContext('test-arn'), replay_status=ReplayStatus.REPLAY
    )
    context_id = parent._peek_next_operation_id()
    child_probe = parent.create_child_context(context_id, is_virtual=virtual)
    wait_id = child_probe._peek_next_operation_id()
    timestamp = datetime(2026, 10, 30, tzinfo=UTC)
    operations = {
        wait_id: Operation(
            operation_id=wait_id, operation_type=OperationType.WAIT,
            status=OperationStatus.SUCCEEDED, name='virtual-wait',
            parent_id=None if virtual else context_id,
            sub_type=OperationSubType.WAIT,
            start_timestamp=timestamp, end_timestamp=timestamp,
        )
    }
    if not virtual:
        operations[context_id] = Operation(
            operation_id=context_id, operation_type=OperationType.CONTEXT,
            status=OperationStatus.STARTED, name='virtual-context',
            parent_id=None, sub_type=OperationSubType.RUN_IN_CHILD_CONTEXT,
            start_timestamp=timestamp,
        )
    state.get_checkpoint_result.side_effect = lambda op_id: (
        CheckpointedResult.create_from_operation(operations[op_id])
        if op_id in operations else CheckpointedResult()
    )
    state.is_operation_updated_since_last_invocation.side_effect = (
        lambda op_id: op_id == wait_id
    )
    child_states = []
    def body(child):
        child_states.append(child.is_replaying())
        child.wait(Duration.from_seconds(5), name='virtual-wait')
        return 'ok'
    result = parent.run_in_child_context(
        body, name='virtual-context', config=ChildConfig(is_virtual=virtual)
    )
    emitted_wait = [
        call.args[0].name
        for call in state.emit_operation_update_hook.call_args_list
    ]
    print({
        'virtual': virtual,
        'child_enters_replay': child_states[0],
        'wait_update_hooks': emitted_wait,
        'result': result,
    })
PYTHON

dev-otel is only the available development environment used to run this probe; the script imports core SDK modules and the Python standard library only. This is an isolated core reproduction, not a new cloud or end-to-end OTel validation.

SDK Version

Runtime reproduction: source checkout 44b9f4d1c862b50041423e19fe6a250bbf7bd72f, whose core package declares 3.0.0.

The same checkpoint-existence predicate and child replay-state inheritance remain in current main 4625d01bbfa97da67050014851af7eb41c61a842, as checked by source comparison on 2026-10-30. The runtime probe above was executed at the first revision; it does not claim a full runtime validation of the later revision.

Python Version

3.15.2, using the existing Hatch development environment on macOS. Other Python versions were not rerun for this report.

Is this a regression?

Unknown; no last-known-working version has been established.

Additional Context

The source path at the reproduced revision is:

1. _replay_aware, context.py:600: while replaying, not next_exists immediately calls _set_replay_status_new(), including for a virtual container.
2. run_in_child_context, context.py:833: the child is created inside that replay-aware scope, after the transition.
3. create_child_context, context.py:444: the child inherits its creator's replay status.
4. The operation-update/replay gate, context.py:564, runs only while replaying. The inner wait bypasses it and returns its stored success.

Suggested acceptance criteria:

• Preserve replay state through virtual-container entry when its inner history still needs replay; switch to NEW when actual new work is reached.
• Exercise initial invocation and resume with step -> wait -> step, checking that completed step bodies do not rerun and the updated wait's normal core notification is delivered once.
• Cover nested virtual contexts, ordinary-child controls, and a virtual context whose next inner operation is genuinely new.
• Preserve virtual checkpoint semantics, stable operation IDs, and wire ParentId; do not fabricate a container checkpoint to obtain replay state.
• Keep rejecting a non-virtual container checkpoint encountered under a virtual child, as required by [Bug]: Virtual child replay can consume a non-virtual container checkpoint #704.

Related but separate:

• [OTel]: Export unvisited replay completions with the correct parent context #854 / fix: export visible replay completions #869 address discovery and export of visible terminal completions in OTel. Plugin-side recovery can mitigate missing telemetry but does not correct this core replay-state transition.
• [Bug]: Virtual child replay can consume a non-virtual container checkpoint #704 concerns replay compatibility when switching a previously checkpointed non-virtual child to virtual.
• [Bug]: wrong replay_status in edge cases #376 concerns invocation-initialization replay state when history is paginated.

This issue is scoped to the Python core replay boundary. Virtual-span ancestry, cross-invocation start-time reconstruction, and execution-wide virtual-span export deduplication should be tracked separately.