[ParidelPooya]

Problem

When an SDK operation exception escapes a child context, map item or parallel branch, ChildContextOperation.handleChildContextFailure checkpoints the inner operation's raw ErrorObject. That is right for a wrapper such as StepFailedException, whose object is the user's original error, but it loses identity for SDK errors that name the failure themselves:

Inside runInChildContext	Invoke/callback throws	Context checkpoint ErrorType before
invoke stopped with States.Stopped	InvokeStoppedException	States.Stopped
invoke stopped with com.acme.PaymentError	InvokeStoppedException	com.acme.PaymentError
invoke timed out	InvokeTimedOutException	no error at all
callback timed out	CallbackTimeoutException	no error at all
callback failed with no type	CallbackFailedException	null type

So a reader of the context checkpoint (telemetry exporters, MapResult consumers, replay) cannot tell what failed the context. Telemetry spec v3 ("Core SDK requirement") requires every failed context to checkpoint the wrapped error, not the wrapper.

Change

ChildContextOperation.wrappedError picks the error to checkpoint:

• CallbackTimeoutException, InvokeTimedOutException, InvokeStoppedException, and a CallbackFailedException or InvokeFailedException whose error has no (or a blank) type: an ErrorObject with ErrorType = the exception's class name, keeping the original message, ErrorData and stack trace when present. For these the raw object is missing or is the stop error, so it does not say what failed the context.
• Any other operation exception (a wrapper such as StepFailedException or a typed callback/invoke failure, a nested ChildContextFailedException, or a DurableOperationException thrown by user code, even with an empty or missing error object): its ErrorObject, unchanged, as before.
• waitForCallback contexts keep the callback's own ErrorObject as before. Live, waitForCallback rethrows the callback's exception (whose error object is the callback's), and a replay of the completed, pruned context can read only the context checkpoint, so the two must hold the same object.

translateException no longer tries to rebuild an SDK operation exception from error data. It falls through to ChildContextFailedException / MapIterationFailedException / ParallelBranchFailedException as before.

User-visible changes

• Context checkpoints (ContextDetails.error) of a context failed by a stopped or timed-out invoke, a timed-out callback, or a typeless callback/invoke failure now carry ErrorType = the SDK exception class name (for example software.amazon.lambda.durable.exception.InvokeStoppedException) instead of the stop error's type, null, or no error.
• The ChildContextFailedException thrown for those contexts carries that ErrorObject, so its message is Child context failed with error of type ...InvokeStoppedException. Message: ... instead of ... of type States.Stopped ... or Child context failed without an error. Its class is unchanged, live and replayed.
• The execution error of a handler that rethrows such a ChildContextFailedException carries that ErrorObject.
• MapResult.getError(i) for such an item is unchanged (it still reports the thrown MapIterationFailedException). Only the iteration's checkpoint changes.
• Unchanged: user errors, wrappers with a typed error, operation exceptions thrown by user code, every top-level operation, and waitForCallback.

Compatibility

• Checkpoints written by older SDK versions still replay: their context errors are read as before.
• Nothing is rebuilt from the new ErrorType values. They are SDK class names that translateException now skips, so replay does not try to deserialize an SDK exception.
• Exception classes, MapResult and the public API are unchanged.

Tests

• New ChildContextWrappedErrorIntegrationTest (LocalDurableTestRunner), each scenario live and replayed (the handler catches, waits for a new invocation, and the replay throws again):
  • child context checkpoint type and message for: step PaymentError; invoke failed with an external type; invoke stopped (States.Stopped, user type); invoke timed out; callback failed (typed, no type, "Error"); callback timed out. Live and replayed failures have the same class and error object.
  • nested contexts (outer > child > invoke) stopped and timed out: both contexts checkpoint the SDK error.
  • map item with a stopped invoke or timed-out callback: the iteration checkpoint carries the SDK error type.
  • waitForCallback: the context keeps the callback's own error object.
• mvn -B install for sdk, sdk-testing, sdk-integration-tests and otel-plugin on JDK 17: 1589 / 53 / 741 / 916 tests passed, 0 failures (5 skipped, all already present). spotless:check passed. The existing PluginErrorContainerCompatibilityTest, WaitForCallbackPrunedReplayTest and otel VirtualOperationErrorStatusTest pass unchanged. The second commit narrows the first one so these pass.
• The full reactor build is in fix(telemetry)!: align error names and log lines with JS #814, which builds on this branch.

Known, not changed here: after the backend prunes a completed waitForCallback context's children, its replay throws ChildContextFailedException while the live run throws CallbackFailedException / CallbackTimeoutException. This was already the case, and WaitForCallbackPrunedReplayTest asserts it. The error object is the same in both runs.

[github-actions]

Codex AI review · Finding arf_v1_kxt4ac5ayulxw4xmu4ktdps4xu

[P2] Preserve callback error identity through enclosing contexts

When a virtual child context calls waitForCallback and the callback times out, the enclosing context now throws ChildContextFailedException with an error object typed CallbackTimeoutException. If the handler catches this and waits, replay prunes the completed wait's children. The wait then throws ChildContextFailedException with a null error object, which wrappedError preserves, so the enclosing failure changes from a typed error to null. Previously, both runs exposed null. This can change error-dependent branches and durable operation sequences during replay. Extend the preservation rule to failures escaping waitForCallback into enclosing contexts, using the persisted wait context's error consistently, and add a virtual-child live/pruned-replay regression test.

To suppress repeats, reply /ai verdict deferred, /ai verdict false-positive, or /ai verdict out-of-scope on the first nonblank line. Add rationale on later lines. A new /ai verdict accepted allows future repeats again.

[github-actions]

Codex AI review

One P2 replay-consistency regression remains at sdk/src/main/java/software/amazon/lambda/durable/operation/ChildContextOperation.java:210. Static review only; tests were not executed.

Reviewed commit 8dde1e75606b29601b642f6884d82794498757bb. Workflow run

[ParidelPooya]

Closing in favour of a simpler approach. We no longer try to make error.name identical across SDKs, and the core SDKs stay unchanged. Each exporter will instead write error and its cause in one shared shape, with each language keeping its own type names; the READMEs will document the differences. A new, smaller exporter-only PR replaces this one. The branch is kept, so this can be reopened if needed.