Expected Behavior
When wait_for_condition resumes and the checkpointed polling state cannot be deserialized, the operation fails with the serdes error.
The Java SDK behaves this way: SerializableDurableOperation.deserializeResult logs a warning and rethrows SerDesException, failing the operation.
Actual Behavior
The SDK catches the exception, logs it, and restarts the condition loop from config.initial_state:
https://github.com/aws/aws-durable-execution-sdk-python/blob/main/packages/aws-durable-execution-sdk-python/src/aws_durable_execution_sdk_python/operation/wait_for_condition.py#L156-L173
All polling progress is discarded and the check function re-runs from scratch. For a condition that accumulates state or counts toward a threshold this produces silently wrong results, and polling can extend past the configured attempt budget because the state driving should_continue_polling restarts from zero.
Trigger conditions: a custom serdes whose deserialize raises, or a serdes/config change deployed while an execution is mid-poll.
Steps to Reproduce
- Configure
wait_for_condition with a custom serdes whose deserialize raises.
- Let the operation checkpoint one continue decision and suspend.
- Resume. The second invocation logs the deserialize failure and continues from
initial_state instead of failing.
SDK Version
1.8.0 (current main)
Is this a regression?
No
Additional Context
Found during the #530 investigation. Defects 1 and 2 there were fixed by #541. This is the remaining case.
The JS SDK has the same silent fallback at its read site in wait-for-condition-handler.ts (catch with no logging). Java propagates. A twin issue is needed on the JS repo.
Proposed fix: remove the fallback and let the serdes error flow through the executor's existing failure path (terminal FAIL checkpoint, surfaced as the typed operation error), matching Java. This is a behavior change, so v2.
Expected Behavior
When wait_for_condition resumes and the checkpointed polling state cannot be deserialized, the operation fails with the serdes error.
The Java SDK behaves this way:
SerializableDurableOperation.deserializeResultlogs a warning and rethrowsSerDesException, failing the operation.Actual Behavior
The SDK catches the exception, logs it, and restarts the condition loop from
config.initial_state:https://github.com/aws/aws-durable-execution-sdk-python/blob/main/packages/aws-durable-execution-sdk-python/src/aws_durable_execution_sdk_python/operation/wait_for_condition.py#L156-L173
All polling progress is discarded and the check function re-runs from scratch. For a condition that accumulates state or counts toward a threshold this produces silently wrong results, and polling can extend past the configured attempt budget because the state driving
should_continue_pollingrestarts from zero.Trigger conditions: a custom serdes whose
deserializeraises, or a serdes/config change deployed while an execution is mid-poll.Steps to Reproduce
wait_for_conditionwith a custom serdes whosedeserializeraises.initial_stateinstead of failing.SDK Version
1.8.0 (current main)
Is this a regression?
No
Additional Context
Found during the #530 investigation. Defects 1 and 2 there were fixed by #541. This is the remaining case.
The JS SDK has the same silent fallback at its read site in
wait-for-condition-handler.ts(catch with no logging). Java propagates. A twin issue is needed on the JS repo.Proposed fix: remove the fallback and let the serdes error flow through the executor's existing failure path (terminal FAIL checkpoint, surfaced as the typed operation error), matching Java. This is a behavior change, so v2.