fix(otel): leave pending invocation spans unset

[zhongkechen]

Summary

• leave invocation span status unset when the durable invocation is pending
• preserve durable.invocation.status=PENDING for lifecycle filtering
• align both OTel plugin implementations and their status-mapping tests

Testing

• hatch run dev-otel:test (92 passed)
• hatch run types:check
• hatch fmt --check in packages/aws-durable-execution-sdk-python-otel

[github-actions]

Claude AI review

No actionable findings.

This PR changes the OTel invocation-span status mapping for PENDING invocations from OK to UNSET in both plugin implementations, and updates the corresponding tests. The review confirms:

• Consistency across implementations: execution_plugin.py:300 and invocation_plugin.py:358 are updated symmetrically, and both explanatory comments now correctly describe PENDING/RETRY -> UNSET.
• Test alignment: The two parametrized status-mapping tests (test_execution_plugin.py:325, test_invocation_plugin.py:178) were both updated to expect StatusCode.UNSET for PENDING.
• Attribute preservation intact: durable.invocation.status is still set unconditionally via set_attribute (execution_plugin.py:296, invocation_plugin.py:350), so PENDING remains queryable for lifecycle filtering, as the PR description claims.
• No stale references: The other two PENDING tests in test_execution_plugin.py (lines 152, 315) assert only span export/non-export, not status code, so they remain valid. No docs, examples, or other packages depend on the old PENDING -> OK mapping.

The change is semantically sound: a PENDING invocation is non-terminal, so leaving the span status UNSET (rather than asserting OK) is the more accurate representation and aligns it with the existing RETRY handling.

Residual test risk: low. The behavioral change is fully covered by the updated parametrized tests. There is no explicit assertion that a PENDING invocation span still carries the durable.invocation.status=PENDING attribute when the span status is UNSET (the attribute-preservation guarantee is exercised only indirectly), but this is a minor coverage gap rather than a defect in the change.

Reviewed commit e402b22f9f3651a12ef43991a4aadb2655320c75. Workflow run

[github-actions]

Codex AI review

No actionable findings. Residual risk is low: both plugin implementations have focused unit coverage, though tests were not independently run under the review constraints.

Reviewed commit e402b22f9f3651a12ef43991a4aadb2655320c75. Workflow run