[Feature]: Unify operation, trace, and span IDs on SHA-256 across SDKs and plugins

Start with cross-SDK design coordination: the issue requires an agreed derivation and migration contract before implementation. Then read Python's identifier.py and deterministic_id_generator.py, alongside the referenced JavaScript and Java generators; run the named derivation tests. Done means shared literal vectors, replay and compatibility coverage, and documented behavior for existing checkpoint histories.

Filed on behalf of parpooya.

What would you like?

Unify core durable operation IDs, OpenTelemetry trace IDs, and span IDs across the SDKs and their plugins using a documented SHA-256-based derivation contract. Equivalent logical operation positions and parent contexts must produce the same core operation IDs; identical execution, operation, and timestamp inputs must produce the same telemetry IDs.

Replace BLAKE2b entirely with SHA-256 throughout the Python SDK and its plugins, including supporting ID-generation helpers. Update the corresponding tests, fixtures, comments, and documentation. Cross-SDK unification and complete BLAKE2b replacement are required outcomes; shared literal test vectors must lock in the agreed behavior.

Core operation IDs and Python replacement scope

The scope includes the actual operation IDs persisted in checkpoints and used for replay lookup. The op-1 input in the telemetry reproduction below is only a supplied operation ID; it does not exercise core operation-ID generation.

Python's OperationIdNamespace.create_id_for_step currently hashes <prefix>-<step>, or the decimal step alone when there is no prefix, using BLAKE2b and takes the first 64 hex characters. Replace this with SHA-256 and coordinate the complete operation-ID contract across SDKs.

The Python production BLAKE2b call sites identified are:

• Core: OperationIdNamespace.create_id_for_step in identifier.py.
• OTel: _to_otel_trace_id, operation_id_to_span_id, derive_workflow_span_id, and derive_execution_root_span_id in deterministic_id_generator.py.

Audit the entire Python repository for additional BLAKE2b-based generation and update all affected packages and fixtures. Core context and concurrency tests currently compute BLAKE2b expectations and also need updating.

Current core hash helpers differ across SDKs: JavaScript hashId uses MD5 truncated to 16 hex characters, Java hashOperationId uses the full 64-character SHA-256 digest, and Python uses BLAKE2b truncated to 64 hex characters. For the raw input 1, source-equivalent calculations give:

SDK	Current core operation-ID hash
JavaScript	c4ca4238a0b92382
Java	6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b
Python	1ced8f5be2db23a6513eba4d819c73806424748a7bc6fa0d792cc1c7d1775a97

Unification must cover raw input construction and nested namespaces as well as the digest and output length. Specify counter origins, parent-prefix construction, delimiters, UTF-8 encoding, and whether nested prefixes contain raw paths or already-derived parent IDs. Add vectors for root operations, child contexts, and map/parallel branches.

Telemetry reproduction and actual behavior

The reported reproduction calls each SDK's real derivation functions locally on main with the same input vector:

Execution ARN: arn:aws:lambda:us-west-2:123456789012:function:probe:live/exec-abc123
Operation ID:  op-1
Start time:    2026-01-01T00:00:00Z

Call the fallback trace-ID, Workflow span-ID, synthetic execution-root span-ID, and operation span-ID derivation functions directly. Render trace IDs as 32 lowercase hexadecimal characters and span IDs as 16 characters.

The reported trace IDs are:

SDK / plugin	Trace ID
JavaScript	feaf1224b9a032585e11c0373b81d306
Java	6955b90082135a58ba5af73a390959cc
Python	6955b900df5592f4f07ad2d543cf206c

JavaScript and Java agree on all three span IDs; Python differs:

Span	JavaScript / Java	Python
Workflow	d0e37fab0e4ce782	f19146248d4ad8dd
Synthetic execution root	f1be6bf8239cec5b	4266148cd134acbf
op-1	60dafeb85e1b1875	c4ebb833f4766696

The Python span values above were calculated from the current source's BLAKE2b derivation while preparing this issue.

Possible implementation

Define one language-neutral SHA-256 derivation contract for core operation IDs and telemetry IDs, covering input encoding, timestamp representation, namespace prefixes, digest truncation, and invalid/all-zero telemetry IDs. The current differences include:

• JavaScript trace ID: first 32 hex characters of SHA-256 of arn + ":" + start.toISOString(); this input serializes the timestamp as 2026-01-01T00:00:00.000Z.
• Java trace ID: 8 hex characters of epoch seconds followed by the first 24 hex characters of SHA-256 of the ARN.
• Python trace ID: the same timestamp prefix approach as Java, but using BLAKE2b for the ARN digest.
• Workflow, execution-root, and operation span IDs use workflow:<arn>, execution-root:<arn>, and <arn>:<operation-id> respectively, truncated to 16 hex characters. JavaScript and Java use SHA-256; Python uses BLAKE2b.

Changing Python's digest alone would therefore not resolve the JavaScript/Java trace-ID difference.

Suggested acceptance criteria:

• Unify core operation IDs and telemetry trace/span IDs on the agreed SHA-256-based contract across SDKs and plugins.
• Replace every Python SDK/plugin BLAKE2b generation path with SHA-256. Update dependent helpers, tests, fixtures, comments, and documentation; verify that no BLAKE2b-based generation remains in the Python implementation.
• Add shared input/output vectors with complete literal operation, trace, and span IDs, including the inputs above and nested/parallel operation namespaces. Expected values must be literals, not recomputed through the implementation being tested.
• Verify initial invocation and replay/resume: completed work is skipped, stored successes and failures are reproduced, parent/child identities remain stable, and side effects occur the expected number of times.
• Preserve valid propagated trace context. Add a JavaScript-to-Python chained-invocation test covering context propagation and fallback behavior when no valid X-Ray context is available.
• Define an explicit migration or version boundary for existing BLAKE2b checkpoint histories before release. An upgrade must not silently cause completed operations to be treated as new, repeat side effects, lose stored failures, or change trace/span identity within an execution.

Is this a breaking change?

Yes for existing persisted identities without a migration or version boundary: core operation IDs are checkpoint lookup keys, so changing them affects replay compatibility and can cause completed work to be missed. Trace/span-ID changes also affect stitching. The SHA-256 rollout must explicitly handle existing histories.

Does this require an RFC?

Yes, or equivalent cross-SDK design coordination, because this changes an existing derivation contract across implementations.

Additional context

Python source review against 4625d01 on main confirms that the generator still uses BLAKE2b. Its Workflow-ID docstring explicitly permits divergence from JavaScript; update that documentation to reflect the unified SHA-256 contract.

The original report identified a lack of literal-value tests. Current Python derivation tests already pin some literal trace and operation span IDs for other inputs. The remaining request is a shared, complete set of cross-SDK vectors and an explicit compatibility contract.

The reported impact is split traces for a JavaScript execution invoking Python on the fallback path. The direct-function reproduction proves identical-input divergence; it does not by itself establish the cause of an end-to-end trace split. Separate executions have different ARNs and require propagated context even with a unified algorithm. The chained-invocation test above should establish the expected behavior.

Evidence is local function-level reproduction with a synthetic ARN. No deployed execution ARN or end-to-end trace capture was supplied; exact original commit SHAs and runtime versions were not recorded in the report.