Skip to content

Clarify attempt counter behavior in DurableLogData under different step semantics #149

@yaythomas

Description

@yaythomas

Problem

The attempt field in DurableLogData does not increment after Lambda sandbox errors when using at-least-once step semantics. This is because uncheckpointed failures are invisible to the attempt counter under at-least-once mode — the failure was not persisted, so from the SDK perspective it never happened.

Under at-most-once semantics, the attempt counter behaves as expected because failures are checkpointed.

This causes confusion when users rely on attempt for observability or retry logic and don't realize the behavior differs between semantic modes.

Related: aws/aws-durable-execution-sdk-js#497

Current state

The step operation docs describe at-least-once vs at-most-once semantics, and the idempotency docs cover replay behavior. However, the docs do not explain how the attempt counter behaves differently under each semantic mode, nor document the specific case of sandbox errors and uncheckpointed failures.

Suggested improvement

  • Add a note to the step operation docs explaining attempt counter behavior under each mode
  • Document that uncheckpointed failures (e.g., sandbox errors) are invisible to the attempt counter under at-least-once
  • Cross-reference from the logging/observability docs

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions