feat(plugin): decouple instrumentation enums from lambda service

[zhongkechen]

Summary

• add plugin-owned InvocationStatus and OperationType enums and convert Lambda service values at the plugin boundary
• update the OTel plugins to depend on the plugin contract and use structural attribute checks for lifecycle payloads
• keep the unpublished instrumentation plugin API at version 1

Testing

• hatch run dev-core:test (1,523 passed, 5 subtests passed)
• hatch run dev-otel:test (115 passed)
• hatch run dev-testing:test (1,365 passed)
• hatch run dev-core:pytest packages/aws-durable-execution-sdk-python/tests/plugin_test.py packages/aws-durable-execution-sdk-python/tests/plugin_discovery_test.py (103 passed, 5 subtests passed)
• hatch run dev-otel:pytest packages/aws-durable-execution-sdk-python-otel/tests/test_plugin_provider.py (5 passed)
• hatch run types:check
• hatch fmt --check for core, OTel, and testing packages

[github-actions]

Claude AI review

Review: decouple instrumentation enums from lambda service

The refactor is complete and internally consistent. I found no actionable correctness, determinism, concurrency, or serialization defects.

What I verified

• Every info-construction site in plugin.py now wraps the service enum through _to_operation_type/_to_invocation_status (from_operation, on_user_function_start, on_operation_action, on_operation_replay, on_child_context_end, on_operation_update, from_durable_execution_invocation_output). UserFunctionEndInfo.from_start_info copies an already-converted value. No site leaks a raw lambda_service enum onto an info object.
• The two plugin-owned enums enumerate exactly the members of the lambda_service originals (OperationType: EXECUTION/CONTEXT/STEP/WAIT/CALLBACK/CHAINED_INVOKE; InvocationStatus: SUCCEEDED/FAILED/PENDING/RETRY), so the value-based Enum(value) conversions cannot raise for current inputs, and the source fields are all non-Optional, so there is no new None.value failure path.
• OTel plugins now import InvocationStatus/OperationType from .plugin, so their is/in comparisons and _TERMINAL_INVOCATION_STATUSES stay same-class against info.status/info.operation_type.
• The structural hasattr swaps are equivalent to the prior isinstance checks for the real payload types: hasattr(info, "is_replay_children") ⇔ UserFunctionStartInfo|UserFunctionEndInfo, and hasattr(info, "is_first_invocation") matches InvocationStartInfo (the only invocation payload passed to _extract_attributes; InvocationEndInfo never reaches it).
• Untouched consumers are unaffected: conformance handlers use .name, examples/core e2e use .value, and the testing package operates on lambda_service Operation/OperationUpdate rather than plugin infos. OperationStatus/OperationSubType were deliberately left on lambda_service, and their consumers still compare like-for-like.

Residual risk (not blocking)

• The two enum definitions must stay value-identical. If lambda_service gains an OperationType/InvocationStatus member that isn't mirrored in plugin.py, _to_operation_type/_to_invocation_status would raise ValueError on the checkpoint hot path (the conversion runs even when no plugins are registered, since it's evaluated before execute_plugins' early return). This is currently guarded only by test_plugin_enums_are_independent_from_service_enums; a defensive fallback or a shared source of truth would harden it, but there is no defect today.
• Behavioral change by design: external plugin authors comparing info.status/info.operation_type against the lambda_service enums (by is or ==) will now silently mismatch, since distinct Enum classes never compare equal even with matching values. All in-repo consumers were migrated; this only affects out-of-tree code and is the intended effect of the change. Test coverage for the conversions is adequate.

Reviewed commit 0a0f9a6e0016e44c2226e517d3851ce791dba4fb. Workflow run

[github-actions]

Codex AI review

[P1] Version this enum identity change as a new plugin API. Existing API-v1 providers remain accepted, but they compare hook values against lambda_service.InvocationStatus and OperationType; these new enum instances are unequal. The previous OTel release consequently misses terminal statuses, fails to export workflow spans, and raises from operation hooks. Either preserve the v1 enum identities or bump DURABLE_INSTRUMENTATION_PLUGIN_API_VERSION, update provider versions/dependency bounds, and reject older plugins. Add a previous-OTel/new-core compatibility test.

[github-actions]

Codex AI review

Found one high-severity plugin compatibility regression. Residual risk: no test covers loading the previous OTel release with the updated core SDK.

Reviewed commit 007eb1c2bf6491660291e93b59abb9971f932ec3. Workflow run

[ayushiahjolia]

Why do we need this change? Are we modifying lambda provided InvocationStatus and OperationType within plugin lifecycle?