feat: expose orchestration context name

[wangbill (YunchuWang)]

Summary

What changed?

• Add getter-only OrchestrationContext.name, populated from ExecutionStarted.name before invoking user code. Logical aliases and case survive replay, including one implementation registered under two names.
• Forward the same metadata through classic context.df.name; do not change registration, version dispatch, or InvocationContext.functionName.

Why is this change needed?

• Orchestrations previously could not read their logical name. This aligns with .NET's TaskOrchestrationContext.Name and invocation-name-backed implementation, rather than deriving identity from the JavaScript function.

Issues / work items

• User-selected orchestration-name parity item; no linked issue.

---

Project checklist

• Release notes are not required for the next release
  • Otherwise: Notes added to CHANGELOG.md
• Backport is not required
  • Otherwise: Backport tracked by issue/PR (none requested)
• All required tests have been added/updated (unit tests, E2E tests)
• Breaking change?
  • If yes:
    • Impact: External custom OrchestrationContext subclasses and typed test doubles must provide the new abstract name getter/property.
    • Migration guidance: Supply the logical orchestration name. SDK-provided contexts need no consumer changes. RuntimeOrchestrationContext constructor arguments are unchanged; manually constructed contexts return "" until history initializes them.

---

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

• No
• Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
• Yes, an AI agent generated most of this PR

If AI was used:

• Tool(s): GitHub Copilot.
• AI-assisted areas/files: Core context/executor, Functions context adapter, focused tests, and changelogs.
• What you changed after AI output: Human review pending; the agent corrected one newly introduced formatting difference.

AI verification (required if AI was used):

• I understand the code and can explain it
• I verified referenced APIs/types exist and are correct
• I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
• I reviewed concurrency/async behavior
• I checked for unintended breaking or behavior changes

Human attestations above are intentionally unchecked; automated evidence follows.

---

Testing

Automated tests

• Result: Passed, 173 tests across 5 suites. Before implementation, all 5 focused name checks failed at runtime (missing metadata), not compilation.
• Covers initial invocation, recorded-name replay across an activity completion, aliases/case, exact-version and unversioned-fallback dispatch, unrelated instance/default-version values, manual construction/getter-only behavior, and classic Functions wrapping through the real in-memory executor.

npx --no-install jest --config .\jest.config.js --runInBand --silent --runTestsByPath .\packages\durabletask-js\test\orchestration_executor.spec.ts .\packages\durabletask-js\test\orchestration_context_methods.spec.ts .\packages\durabletask-js\test\versioned-dispatch.spec.ts .\packages\durabletask-js\test\versioned-in-memory.spec.ts .\packages\azure-functions-durable\test\unit\orchestration-context.spec.ts
npm run build -w durable-functions
git diff --check origin/main...HEAD

• Core and Functions builds passed. Emitted declarations reject name assignment on all three context types (expected TS2540).
• Scoped ESLint and normal Husky/lint-staged passed. A baseline-aware Prettier comparison found no new formatting deviations; pre-existing formatting and CRLF were preserved rather than reformatting unrelated code.
• The initial local implementation validation did not run full suites, sidecar/Azure/emulator/Functions-host E2E. A follow-up on 2026-09-28 tested unchanged head 9d29d57 against a new isolated task hub on the real Azure DTS production service: 3/3 E2E tests passed, covering two aliases of one implementation and parent/child logical names across actual activity/timer replay. Four instances persisted Completed; all four were individually purged and read back absent. Fresh exact-head evidence, cleanup status, and limitations. This is not an Azure Functions host deployment test.

Manual validation (only if runtime/behavior changed)

• Environment (OS, Node.js version, components): Windows, Node.js v24.14.0, real executor and in-memory backend.
• Steps + observed results: Initial runtime/replay checks were local; the subsequent real Azure DTS run and its limitations are linked above. No separate manual Functions-host validation.
• Evidence (optional): Test/build/lint/type-check logs retained as local session artifacts.

---

Notes for reviewers

• Scope is orchestration logical-name metadata only: four production files, two existing test files, and two changelogs.

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved review issues were identified, and the supplied tests cover the changed behavior.

Review effort: Lite
Findings: None

What changed in this PR

Adds replay-safe logical orchestration names to core and classic Durable Functions contexts.

Changes:

• Adds getter-only OrchestrationContext.name.
• Initializes the name from execution history.
• Forwards it through context.df.name.
• Adds tests and changelog updates.

File	Description
packages/​durabletask-js/​test/​orchestration_executor.spec.ts	Tests initialization, replay, aliases, and getter behavior.
packages/​durabletask-js/​src/​worker/​runtime-orchestration-context.ts	Stores and exposes the orchestration name.
packages/​durabletask-js/​src/​worker/​orchestration-executor.ts	Initializes the name from execution history.
packages/​durabletask-js/​src/​task/​context/​orchestration-context.ts	Defines the public name getter.
packages/​azure-functions-durable/​test/​unit/​orchestration-context.spec.ts	Tests classic context integration.
packages/​azure-functions-durable/​src/​orchestration-context.ts	Forwards the name through context.df.
packages/​azure-functions-durable/​CHANGELOG.md	Documents the classic API addition.
CHANGELOG.md	Documents the core API and breaking change.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[wangbill (YunchuWang)]

Real Azure DTS E2E — PASS at 9d29d57

On 2026-09-28, validated unchanged head 9d29d5753208f6b40a0c981f4764b087160809c9, tree ded42961c674d3bb98b8d962f75fe9f6781b9e59, against the real public Azure DTS production service in West US 2. The run used a new isolated Consumption scheduler/task hub in Private Test Sub WANGBILL and Azure CLI authentication over TLS, not a customer workload, emulator or mocked backend.

3/3 tests passed, one suite, zero failures/skips/open handles; Jest exited normally in 26.622 seconds. Authenticated Hello and absent-instance GetInstance preflight succeeded on the first attempt.

Case	Actual service and persisted-history evidence
One native implementation registered as MiXeDAlpha, version 1.0.0	ctx.name preserves the scheduled logical alias/case at initial entry, after an actual activity completion, and after a durable timer fires; persisted output and ExecutionStarted.name agree.
The same implementation registered as MixedBeta, version 2.0.0	Independently reports its own alias through the same initial/replay path rather than the native function name or another registration.
Parent/child aliases	The parent reports its own logical name; the actual sub-orchestration reports its child name, not the parent's name/instance ID or the unrelated worker default. Both complete with matching persisted names and history.

Observed 4 Completed instances, 11 actual orchestration work items / wire ExecutionStarted observations, 4 initial entries and 7 replay entries, with 3 activity completions, 3 timer firings and 1 sub-orchestration completion. Passive observers forwarded the real gRPC streams unchanged; they did not fabricate work items or inject history.

All four exact test-owned root/child IDs were individually purged (deletedInstanceCount=1 each) and read back absent. All workers, clients and the test process stopped normally; the test-only overlay was archived and removed, leaving the production checkout clean and unchanged. All task-owned Azure resources have now been deleted: temporary data role, task hub, scheduler and resource group. Azure confirmed the resource group absent at 2026-09-28T17:06:45Z. No customer resources were touched.

Scope and reproduction

• Command: npx --no-install jest --config .\jest.config.js --runInBand --detectOpenHandles --runTestsByPath .\test\e2e-azuremanaged\context-name-production.spec.ts --json --outputFile <artifacts>\azure-name-jest.json.
• Node.js 24.14.0; an archived temporary integration overlay uses the existing SDK/Jest tooling. No committed source/dependency changes or new pushes were needed.
• Evidence index: azure-name-summary.json; detailed states, histories, wire observations and cleanup: azure-name-evidence.json. Evidence SHA-256: 53f40463bebc8b96f9e16f39332c2b702396df3fbd459ffe46e330d4c8bc8770. Exact overlay SHA-256: 5261806ca05266795c766f3ebbeaf7c6d5e18326fba7d3e1b42efc94bdbd9003.
• This does not claim an actual Azure Functions host deployment, load/chaos coverage, or case-only alias collision semantics. It verifies case preservation for distinct mixed-case aliases. These fresh three service tests are separate from the earlier 173 local tests.