fix(plugin): surface missing state fields on hook info records

[wangyb-A]

Summary

Plugin hook info records dropped state that the Python and JS SDKs carry, so a Java plugin could not see per-operation replay status at the attempt and change hooks, nor operation state at the invocation hooks.

Bottom of a 2-PR stack. The conformance handlers that assert these field shapes — and the live suite results — are in the stacked follow-up. This PR is the SDK change only and is reviewable on its own.

What changed

Execution payload surface (JS parity)

• InvocationInfo gains executionInput: the deserialized input the execution was started with — the same value the durable handler receives.
• InvocationEndInfo gains executionInput (carried through from the start hook) and executionResult, the value the handler returned. executionResult is populated only when the invocation completed the execution successfully; null for PENDING/FAILED/RETRYING.
• Both are typed Object, matching JS's unknown. Note Python instead exposes execution_result as the serialized string from the invocation output; Java follows the JS shape and reports the returned object.

Ordering change — please review. The execution input is now deserialized before onInvocationStart fires, because the hook must carry it. Deserialization can fail, so the failure path explicitly fires the start hook with a null executionInput before propagating: plugins must observe an invocation-start for every invocation, including one with a malformed input payload. A regression test covers this using a SerDes that rejects every deserialize.

Operation result (JS parity)

• result added to the three operation-snapshot records: OperationInfo, OperationEndInfo and OperationChangeItemInfo.
• It is the operation's checkpointed serialized result, exactly as the backend recorded it, typed String to match JS's result?: string. The serialized form is deliberate — the plugin boundary has no access to the caller's target type, so it cannot deserialize. Null when the operation produced none (still running, failed, or a type carrying none such as WAIT).
• The payload lives on a different *Details member per operation type, so BaseDurableOperation.getResultPayload dispatches on operation type exactly as the existing getErrorObject does (STEP, CHAINED_INVOKE, CALLBACK, CONTEXT).

Attempt and change-item fields

• UserFunctionStartInfo / UserFunctionEndInfo gain isReplay, the operation-level indicator for whether THIS operation was observed via checkpointed state. Distinct from the existing isReplayingChildren, which describes the child operations of a context body and does not substitute for it.
• OperationChangeItemInfo was a reduced record. It now carries the full operation surface (status, attempt, isReplay, error), ordered to match OperationEndInfo, so an operation observed through a change delta exposes the same fields as through the per-operation hooks.

Invocation-info enrichment

• InvocationInfo gains operations and updatedOperations.
• InvocationEndInfo gains operations and executionStartTime. The latter was present on the start info but dropped from the end record, forcing plugins to correlate back to the start hook.
• updatedOperations derives from the invocation input's UpdatedOperationIds intersected with the tracked operations, so it is empty on the first invocation and names the externally-completed operations on a replay.
• The end-info snapshot is taken at end time, so unlike the start info it also includes operations created during the invocation.

Design notes for reviewers

Where the replay indicator comes from. The attempt hook needs the operation-level replay flag at its firing site in BaseDurableOperation.runUserFunction, but getOperation() delegates to getOperationAndUpdateReplayState, which flips REPLAY to EXECUTION mode as a side effect. Reading it from a plugin-hook site would mutate execution state. ExecutionManager instead snapshots the operation ids delivered in the initial state once, and wasObservedAtInvocationStart is a pure containment check. That yields one consistent definition of isReplay across the attempt, change and invocation hooks: the operation predates this invocation.

Map value type. Both invocation maps are keyed by operation id and valued with OperationChangeItemInfo, now the richest operation snapshot record the SDK has, so a single conversion path (PluginInfoConverter.toOperationItemMap) feeds the change hook and both invocation hooks. The record's name is a wart in this role; renaming it to something like OperationItemInfo is a reasonable follow-up, kept out of this change to limit blast radius.

No defaulting constructors. These are positional records, so the added components surface every constructor call site at compile time. I deliberately did not add convenience overloads: a defaulting constructor is exactly how a future internal call site would silently ship empty maps to plugins, which is the failure mode this fixes. Call sites in the OpenTelemetry plugin tests were updated mechanically. All touched APIs are @Deprecated preview, so the record-shape changes are sanctioned.

Out of scope

• Requirement 10-14 / Add plugin conformance case 10-14 (known SDK gap) #581 — coordination needed. 10-14 asserts an operation-end result and has a standing red-test branch (Add plugin conformance case 10-14 (known SDK gap) #581). This PR supplies the SDK surface that requirement needs, so Add plugin conformance case 10-14 (known SDK gap) #581 is expected to go green once this lands. 10-14's handler still lives on that separate branch, so it continues to report UNCOVERED in this stack's runs. Worth sequencing with whoever owns Add plugin conformance case 10-14 (known SDK gap) #581.
• Requirement 10-18 / Add plugin conformance case 10-18 (known SDK gap) #582 (Java never fires onOperationStart with isReplay=true for a pending WAIT) is a separate behavioral fix with OpenTelemetry span-model coupling. Not bundled here.

Testing

Full module build, unit tests and spotless:check: BUILD SUCCESS. SDK 1129 tests, integration 400, OpenTelemetry 165, examples 120 — all green. The first commit was additionally verified applied directly to main with no handler code present.

Adds six PluginIntegrationTest cases: execution input and result on success, no execution result when suspended, none when the execution fails, the start-hook-fires-on-malformed-input invariant, and operation-end reporting the serialized result on success versus no result plus an error on failure.

Known flaky test, not caused by this PR: InvocationOtelPluginTest.invocationEnd_closesNestedSpansChildFirst (a test added on main) failed 3 times across ~12 full-reactor runs on this branch, and 0 times across 8 runs on pristine main; it passes 6/6 in isolation on both. This PR changes no OpenTelemetry production code (git diff main HEAD -- otel-plugin/src/main is empty) and the span close order in endOpenSpansChildFirst is deterministic, so the correlation looks like timing sensitivity in the test rather than a behaviour change. Flagging rather than hiding it.

Conformance evidence lives in the stacked follow-up, where the handlers exist to assert these shapes: 21/21 covered plugin requirements pass, with 10-19, 10-21 and 10-22 flipping to green.

Refs: #604

[github-actions]

Claude AI review

No blocking findings. The diff is a mechanically consistent, compile-safe expansion of the preview (@Deprecated) plugin-hook record surface.

Verified:

• Every positional constructor/factory call site for the changed records (InvocationInfo, InvocationEndInfo, UserFunctionStartInfo, UserFunctionEndInfo, OperationChangeItemInfo) and the changed PluginInfoConverter/ExecutionManager methods is updated in-diff across all modules; consumers use name-based accessors, so the OperationChangeItemInfo field reorder does not break any reader. Compilation is sound.
• wasObservedAtInvocationStart is a pure Set.contains over initialOperationIds (snapshotted once at construction), so reading isReplay at the attempt/change/invocation hook sites does not mutate replay mode — a real hazard the design correctly avoids. The isReplay definition is consistent across all three hook families.
• toOperationItemMap builds maps keyed by unique Operation::id with non-null values (no duplicate-key/NPE risk), and getUpdatedOperationsSnapshot filters nulls. Empty-not-null invariants hold; updatedOperations is empty on first invocation.
• attempt extraction mirrors the pre-existing toOperationEndInfo exactly, so it introduces no regression. fireOnInvocationEnd runs while the ExecutionManager is still open.

Residual test risk (this PR only): The behavioral additions in this PR are effectively unverified here. The only test changes are mechanical constructor-arity updates to existing OTel/unit tests plus one isReplay assertion on toUserFunctionStartInfo. There is no unit test in this PR for: the new public PluginInfoConverter.toOperationItemMap; the new attempt/isReplay fields on OperationChangeItemInfo; toOperationChangeInfo's new replayedOperationIds argument; the new ExecutionManager methods (wasObservedAtInvocationStart, getInitialOperationIds, getOperationsSnapshot, getUpdatedOperationsSnapshot); or the populated operations/updatedOperations/executionStartTime on the invocation records. The PR defers these assertions to a stacked follow-up. Recommend adding SDK-module unit tests in this PR (e.g. in PluginInfoConverterTest/an ExecutionManager test) covering the isReplay/attempt population and the initial-vs-updated snapshot partitioning, so the new surface is guarded independently of the follow-up branch.

Note: the PR description references executionInput, executionResult, an operation result field, and a getResultPayload dispatcher that are not present in this diff; those were not reviewed as they are not part of these changes.

Reviewed commit 4f5639c25b35c389f90a7af14b147ae251b424e4. Workflow run

[zhongkechen]

Confusing. Can we find a better name and explain the behavior better?

[wangyb-A]

only keep isReplay to match js

[zhongkechen]

The interface hasn't released for js yet. We can rename for both Java and JS if we have a better name

[wangyb-A]

I think we can keep this name isReplay, since this apply to all operations, not limited to child context operation, do you have any suggession on this?

[zhongkechen]

Confusing. What's the difference from above? Can we find a better name and explain the behavior better?

[wangyb-A]

only keep isReplay to match js

[zhongkechen]

Same as the above. isReplayingChildren could be renamed.

[github-actions]

Codex AI review

Three public plugin API regressions need correction. Residual risk: runtime tests were not executed under the read-only review constraint.

Reviewed commit 726603271f06e136c1602bab0177420fef8cf6e6. Workflow run