[Feature]: durable execution event hooks

[zhongkechen]

What would you like?

• onOperationStart, onOperationEnd, onOperationAttemptStart, onOperationAttemptEnd fire at most once per operation/attempt.
• onOperationAttemptStart and onOperationAttemptEnd will manage a span that is a child of the span managed by onOperationStart and onOperationEnd. That is retry attempts for steps and wait-for-condition operations.
• onExecutionStart, onExecutionEnd fire at most once per execution
• onInvocationStart, onInvocationEnd fire at most once per invocation

proposed design doc: https://github.com/aws/aws-durable-execution-sdk-js/blob/otel-instrumentation-design-v2/packages/aws-durable-execution-sdk-js/src/documents/PYTHON_SDK_OTEL_PLUGIN.md

Key Differences

There is a key difference in this implementation from JavaScript implementation

• Python calls onOperationAttemptStart when an attempt is started , while JS calls it when the attempt is completed
• Python calls onOperationStart when an operation is started, while JS calls it when the operation is completed

Possible Implementation

Similar work in TypeScript SDK for reference:

• notes about plugin interface: https://github.com/aws/aws-durable-execution-sdk-js/blob/otel-instrumentation-design-v2/packages/aws-durable-execution-sdk-js/src/documents/PLUGIN_IMPLEMENTATION.md

• plugin interface: https://github.com/aws/aws-durable-execution-sdk-js/blob/otel-instrumentation-design-v2/packages/aws-durable-execution-sdk-js/src/types/plugin.ts

• To see how onOperationStart, onOperationEnd, onOperationAttemptStart, onOperationAttemptEnd are currently wired in the TS SDK, you'll have to check the branch. For example, onOperationStart.

• wiring of onExecutionStart, onInvocationStart, onExecutionEnd, onInvocationEnd: https://github.com/aws/aws-durable-execution-sdk-js/blob/otel-instrumentation-design-v2/packages/aws-durable-execution-sdk-js/src/with-durable-execution.ts

• how TS dash0 plugin (v1) deals with duplicate span creations: aws/aws-durable-execution-sdk-js@d75518f#diff-d172a83e0787d5e5a395b4167323ac0d2e24043acca5355467f50a5b7390b7d0

Is this a breaking change?

No

Does this require an RFC?

Yes

Additional Context

No response