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.
• Full suites, sidecar/Azure/emulator/Functions-host E2E were not run locally; hosted CI is not claimed.

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: No separate manual or Azure validation; runtime/replay behavior was checked by the automated tests above.
• 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.