Add plugin conformance case 10-18 (known SDK gap)

[wangyb-A]

Summary

Test case for #580

[github-actions]

Codex AI review

• [P1] Do not enable an unpassable conformance case — conformance-tests/template_plugin.yaml:311. The current SDK explicitly omits replayed onOperationStart hooks for non-terminal waits, so 10-18 cannot pass. Registering it makes the plugin conformance job fail for this and subsequent relevant PRs. Implement the wait replay hook with replay coverage before registering 10-18, or leave TestDescription empty until that fix lands.

Reviewed commit 65962a6e9368a1936354f6128d7eee85ad07a33b. Workflow run

[github-actions]

Claude AI review

No actionable findings.

This PR adds a single plugin conformance handler (conformance-tests/src/main/java/plugin/PluginWaitReplayFlag.java) and its SAM function resource (conformance-tests/template_plugin.yaml:307) for requirement 10-18. The change is scoped to the conformance-test harness and does not touch SDK runtime code.

Verification performed

• API correctness — context.parallel(String, ParallelConfig), parallel.branch(name, Class, fn), and branch.wait(String, Duration) are all valid (DurableContext.java:214 provides Void wait(String, Duration)). OperationInfo.isReplay()/name()/endTimestamp() and OperationEndInfo.name()/type()/status() exist with the used signatures. The try (parallel) { … } return futures.stream().map(DurableFuture::get).toList(); shape (getting results after close()) matches the established PluginParallelBranchHooks pattern.
• pending discriminator soundness — PluginInfoConverter.toOperationInfo sets endTimestamp from the operation (null when the op is absent or still running), so endTimestamp() == null is a correct non-terminal indicator both on first start and on a hypothetical fixed replay path; isReplay is derived from operation != null, giving the intended {replay=true, pending=true} if/when the SDK gap is closed.
• Intentional red test confirmed — BaseDurableOperation.execute() (lines 142–147) fires onOperationStart on non-terminal replay only for STEP/CONTEXT; WAIT/INVOKE/CALLBACK deliberately do not. The still-pending 8s WAIT is therefore never re-emitted on replay, so the {name=long, replay=true, pending=true} assertion gets zero matches. This matches the PR's documented, expected-to-fail behavior (no-masking tracking signal), not a handler bug.
• Conventions — copyright header, @SuppressWarnings("deprecation"), Locale.ROOT uppercasing, PluginSupport.arnField/isWait usage, and the volatile-executionArn capture all align with sibling handlers. The YAML resource mirrors the other Plugin* entries (CodeUri, Handler, Role GetAtt, RetentionPeriodInDays: 7, ExecutionTimeout: 300).
• Tests — the conformance-tests module has no src/test; handlers are exercised by the external conformance suite, so the absence of a unit test here is consistent with all 19 existing plugin handlers.

Residual test risk
The handler is authored to fail (red) until the SDK extends the replay onOperationStart notification to non-terminal WAIT/INVOKE/CALLBACK operations. This is intentional per the conformance suite's no-masking principle, but reviewers/CI must treat this specific case as an expected failure rather than a regression until the SDK gap is closed. The scenario also depends on the external harness suspending between the 2s and 8s wait completions; if a future harness change coalesced polling into one warm invocation without suspension the observed records would differ, though that is outside this handler's control.

Reviewed commit 65962a6e9368a1936354f6128d7eee85ad07a33b. Workflow run