feat(ContextPropagator): Replace imperative set/unset context propagation with lexically-scoped runWithContext (v3.13.x backport)

[rlei]

Backport of #1074 to the v3.13.x branch, so the team can pick it up without needing a dirty cherry-pick against the diverged master history.

Why

JDK 25 finalizes ScopedValue (JEP 481), a lexically-scoped, immutable alternative to ThreadLocal for propagating context: a value is bound and the task runs inside that binding in a single call (ScopedValue.where(...).call(task)), with no separate unset step -- the binding is torn down automatically when the call returns. The previous ContextPropagator API couldn't express that: context was installed via setCurrentContext/deserializeContext at the top of a handler and torn down via unsetCurrentContext in a finally block possibly several methods away, which doesn't map onto ScopedValue's single-call binding model.

Restructuring around a single runWithContext(context, task) call gets us:

• Simplicity: a ScopedValue-backed propagator only needs to override runWithContext and call ScopedValue.where(VALUE, context).run(task) -- no separate set/get/unset methods to keep consistent with each other.
• Immutable context data: ScopedValue bindings are write-once for the dynamic extent of the call; nothing downstream can accidentally mutate a shared context object the way a mutable ThreadLocal value can.
• No unpaired unset: because the binding and the task execution happen in the same call frame, cleanup is guaranteed by stack unwinding. The old shape's risk -- an early return, a thrown exception before the try block, or a future refactor splitting set/unset further apart leaving a propagator's context set with no matching unset and leaking it onto whatever task a pooled thread picks up next -- goes away entirely.

Change

• Add ContextPropagator.runWithContext(Object context, ContextRunnable task), a default method that wraps setCurrentContext/task.run()/unsetCurrentContext in a single try/finally, so set and unset are always paired in one call frame.
• ContextThreadLocal.runWithContext(...) composes all configured propagators into a single nested call chain and executes the task inside it, replacing the old propagateContextToCurrentThread + manual unsetCurrentContext pair.
• Update the three call sites (ActivityWorker, LocalActivityWorker, WorkflowThreadImpl) to run their task through this single call instead of bracketing it with separate propagate/unset calls.

Existing propagators that implement setCurrentContext/unsetCurrentContext are unaffected; runWithContext has a default implementation built on those methods, so this is additive for current implementations and opt-in for ScopedValue-based ones.

Test plan

• ./gradlew test --tests "com.uber.cadence.internal.context.*" --tests "com.uber.cadence.internal.worker.*" --tests "com.uber.cadence.internal.sync.*" passes against v3.13.x (Docker build, JDK 11 / thrift 0.9.3 toolchain matching this repo's CI image; version string confirms 3.13.3-1-g01b4ed5).

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

[gitar-bot]

CI failed: Unit test failures occurred across CI jobs due to failing test assertions in the test suite.

Overview

CI runs encountered test failures in the Gradle :test task (1 test failure in the standard unit test run and 3 test failures in the Docker service test run), directly related to the changes introduced in the PR.

Failures

Gradle Unit Test Failures (confidence: high)

• Type: test
• Affected jobs: 94580624034, 94827982305
• Related to change: yes
• Root cause: Unit tests failed during execution of the Gradle :test task (1 failing test in standard tests, 3 failing tests in Docker-based sticky-off tests), likely caused by test assertions affected by the new runWithContext ContextPropagator implementation or related changes.
• Suggested fix: Review the Gradle test report files at build/reports/tests/test/index.html to identify the failing tests, verify the test assertions and logic against the updated context propagation behavior, and fix any incorrect expectations or code issues.

Summary

• Change-related failures: 2 job failure groups involving unit test failures in the Gradle build.
• Infrastructure/flaky failures: 0
• Recommended action: Inspect the local or artifact test reports for the exact stack traces and failing test names, then update the tests or implementation to ensure proper context propagation and correct test expectations.

Code Review ✅ Approved 1 resolved / 1 findings

Backports lexically-scoped runWithContext propagation to replace imperative set/unset calls, addressing the invocation-count violation exception-discarding finding. No issues found.

✅ 1 resolved

✅ Quality: Invocation-count violation discards the triggering exception

📄 src/main/java/com/uber/cadence/internal/context/ContextThreadLocal.java:118-121 📄 src/main/java/com/uber/cadence/internal/context/ContextPropagatorContractViolationError.java:49-60
When a propagator retries the task after catching a failure, thrown holds the original exception that triggered the retry, but unexpectedInvocationCount(applied, count) is called with a null cause (ContextThreadLocal.java:118-120, ContextPropagatorContractViolationError.java:49-60), so the diagnostic stack trace of the underlying failure is lost. Consider passing thrown.get() as the cause when non-null to aid debugging of the misbehaving propagator. The existing test asserts e.getCause()==null, so this is a deliberate choice, but attaching the cause would make production diagnosis easier.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}