feat(plugin): surface execution input and result on invocation hooks

[wangyb-A]

Summary

Widens the plugin invocation hooks so instrumentation plugins can record execution
input/output:

• InvocationInfo.executionInput — the deserialized handler input
• InvocationEndInfo.executionInput — the same value, so end-only plugins need not cache it
• InvocationEndInfo.executionResult — the value the handler returned, populated only when the
  invocation completed the execution successfully (null on FAILED / PENDING / RETRYING)

Motivation

The JS SDK already exposes this to plugins (InvocationBaseInfo.executionInput,
InvocationEndInfo.executionResult), and the Python SDK added the equivalent in
aws-durable-execution-sdk-python#616. Java is the only SDK where a plugin cannot see execution
I/O at all, which blocks the Workflow Insight plugin from emitting the input/output fields
its record schema defines — it currently omits them rather than fabricating them. This is the
one remaining hook-surface gap of the two found by cross-SDK conformance validation (the other,
per-operation result, is #596).

Compatibility

Both records keep a constructor at their previous arity, delegating with nulls:

new InvocationInfo(requestId, arn, isFirstInvocation, executionStartTime);              // still compiles
new InvocationEndInfo(requestId, arn, isFirstInvocation, status, executionError);       // still compiles

So existing callers — including otel-plugin's tests, which construct these directly — compile
unchanged; nothing outside sdk/ needed edits. Adding a record component alone would have been a
source-breaking change to an API that #620 just promoted to stable.

Cost and failure behavior

• The plugin-facing deserialization is skipped entirely when no plugins are registered
  (PluginRunner.isEmpty()), so plugin-less executions pay nothing.
• If the input cannot be deserialized, the hook value is null rather than propagating; the
  authoritative extraction still surfaces the error at its original point. This keeps hook
  ordering intact — plugins continue to receive onInvocationStart before any input-extraction
  failure, so a plugin keying state on start never sees an end without a start.

Preview marking

The new components are marked @Experimental, matching the convention #620 established when it
replaced the preview-API @Deprecated markers — the same idiom already used by
@Experimental Throwable executionError in this record.

Testing

• PluginRunnerTest — 13 pass, including 4 new: the compatibility constructors leave the new
  components null, and the canonical constructors carry input/result
• PluginIntegrationTest — 28 pass, including 3 new end-to-end through the real executor:
  input reaches both hooks and the result appears on success; result is null on failure and on
  suspension (PENDING)
• Full reactor: sdk 397 tests, otel-plugin 165 tests, all green; mvn spotless:check clean

[github-actions]

Codex AI review

No actionable findings. Residual risk: the added integration tests do not cover successful replay or RETRYING hook payloads. Tests were not run per review constraints.

Reviewed commit 38dbb45d6c072402fa3d3fb39e1624a8d3f986f5. Workflow run

[github-actions]

Claude AI review

Review — no blocking findings

This PR widens the plugin invocation hooks to surface deserialized execution input (InvocationInfo.executionInput, InvocationEndInfo.executionInput) and the handler's return value (InvocationEndInfo.executionResult). The implementation is correct and well-covered.

Verified in detail:

• Argument ordering across all four end branches in DurableExecutor (PENDING/RETRYING/FAILED/SUCCEEDED) matches the new canonical InvocationEndInfo(requestId, arn, isFirstInvocation, status, error, executionInput, executionResult) component order. executionResult is passed only on SUCCEEDED; null elsewhere.
• Cross-thread publication via pluginExecutionInput (AtomicReference): set on the handler thread before any suspend point, read on the completing thread — visibility is guaranteed, and it is always set before any suspension/failure that could fire onInvocationEnd.
• Hook pairing on deserialization failure: extraction failure is captured, onInvocationStart still fires (with null input), then the original Throwable is re-thrown unchanged via sneakyThrow, preserving its type/stack and FAILED classification. Input is deserialized exactly once and shared with the handler.
• API compatibility: the previous-arity constructors are retained as delegating constructors; the only external caller (examples/.../PluginExample.java, otel-plugin tests) is unaffected.
• PII protection: toString() overrides on both records exclude the new payload components, with unit-test coverage.

Residual test risk (not blocking):

• The RETRYING branch (sdk/src/main/java/software/amazon/lambda/durable/execution/DurableExecutor.java:142) now also carries executionInput, but no end-to-end test exercises it; its logic is identical to the other branches (pluginExecutionInput.get()), so risk is low.
• Deserialization now runs before onInvocationStart (previously after). A custom SerDes or any logging emitted during deserialization no longer runs inside a plugin's onInvocationStart ThreadLocal/MDC setup. This is inherent to passing deserialized input to the start hook and is an intentional, documented trade-off, but the ordering change is undocumented in the hook contract — worth a note if any plugin relies on that ordering.

Reviewed commit 38dbb45d6c072402fa3d3fb39e1624a8d3f986f5. Workflow run