Add Functions gRPC core helpers

[YunchuWang]

What

Adds the minimal host-integration surface so Azure Functions can drive a single durable work item per invocation, without running the long-lived gRPC worker loop. This mirrors the Azure Functions consolidation done for Python in durabletask-python PR #155.

API

Two methods on TaskHubGrpcWorker:

• processOrchestratorRequest(request: Uint8Array): Promise<Uint8Array>
• processEntityBatchRequest(request: Uint8Array): Promise<Uint8Array>

Each deserializes a TaskHubSidecarService protobuf payload, executes one work item, and returns the serialized response. Host integrations own any transport encoding (for example base64); base64 stays out of the core SDK.

Design (aligned with Python #155)

Rather than refactoring the worker, these methods reuse the worker's existing internal execution path (_executeOrchestratorInternal / _executeEntityInternal) and pass an in-process CapturingSidecarStub that records the completion payload instead of sending it over gRPC. This is the same null-stub pattern Python uses (AzureFunctionsNullStub).

Deliberately NOT included (kept minimal)

• No base64 protobuf helper module (transport detail belongs in the host).
• No object-level execute* public methods (the byte processors are the single entry point).
• No V2 EntityRequest host path (not present in Python fix: Reset customStatus on continue-as-new in InMemoryOrchestrationBackend #155; the worker's internal V2 handling for the DTS backend is unchanged).
• No new client options; task-hub routing metadata continues to flow through the existing metadataGenerator.

Tests

packages/durabletask-js/test/functions-grpc-support.spec.ts covers both byte processors end to end.

[Copilot]

Pull request overview

Adds a minimal “single work-item” execution surface to the Durable Task JS worker so host integrations (e.g., Azure Functions) can execute one orchestrator/entity batch request per invocation without running the long-lived gRPC streaming loop. This aligns with the SDK’s role as a low-level Durable Task Scheduler (sidecar) client/worker implementation.

Changes:

• Added byte-level helper methods on TaskHubGrpcWorker to process serialized OrchestratorRequest / EntityBatchRequest payloads and return serialized responses.
• Introduced an in-process CapturingSidecarStub that captures completion payloads instead of sending them over gRPC.
• Added end-to-end tests and README documentation for the new host-integration surface.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
README.md	Documents the new low-level host integration APIs and clarifies the non–Durable Functions programming model scope.
packages/durabletask-js/test/functions-grpc-support.spec.ts	Adds e2e-style tests covering the new byte processors for orchestrations and entities.
packages/durabletask-js/src/worker/task-hub-grpc-worker.ts	Implements the new public byte-processing methods and the capturing sidecar stub.

[YunchuWang]

TODO: remember to bump this to 0.4.0, and we need to release @microsoft/durabletask-js first

also confirm whether @azure/functions 4.16.1 has the extension changes required,

[YunchuWang]

addressed in f935bce

[YunchuWang]

Release-readiness findings (version bump to 0.4.0 is done in code; the two open items below are release-time actions):

1) @azure/functions 4.16.1 floor — confirmed adequate.

• v4.16.0 carried the substantive change: bumped @azure/function-extensions-base 0.2.0 → 0.3.0 and dropped Node 18 from CI (which lines up with this package's Node >= 22 floor).
• v4.16.1 is a security-servicing release over 4.16.0 (MSRC updates); v4.16.2 is functionally identical to 4.16.1 (only reclaimed the npm latest tag from an erroneously published 3.6.0).
• This package uses only stable generic-binding APIs (trigger.generic / input.generic carrying durableRequiresGrpc), available since v4.0, and does not depend on @azure/function-extensions-base directly. So ^4.16.1 is a sound "recent + security-patched" floor (it resolves to 4.16.2 today). The actual durable-gRPC enablement (durableRequiresGrpc → gRPC channel) is host-extension-side, not gated by the npm library version.

2) Core release ordering — a real blocker to verify before publish.

• The core package (@microsoft/durabletask-js) on this branch still declares version: 0.3.0, but it adds new public APIs this package relies on (processOrchestratorRequest, addNamedOrchestrator, CapturingSidecarStub, …). The published 0.3.0 on npm does NOT contain those.
• This package's dependency is pinned to "@microsoft/durabletask-js": "0.3.0". Locally the monorepo workspace links the in-tree core (which has the new APIs), so E2E passes; but once published to npm, 0.3.0 would resolve to the old published core and fail at runtime (processOrchestratorRequest is not a function).
• Release checklist: (a) bump the core version (e.g. 0.4.0) and publish @microsoft/durabletask-js first; (b) update this package's dep from 0.3.0 to the new core version (0.4.0 / ^0.4.0); (c) then publish durable-functions@0.4.0.

Leaving this thread open until the core is released and the dependency is bumped.

[andystaples]

Review summary

Two things ship here: (1) the advertised core gRPC byte-processors (processOrchestratorRequest / processEntityBatchRequest + CapturingSidecarStub) in task-hub-grpc-worker.ts, and (2) an entire new durable-functions@4.0.0-alpha.0 package (packages/azure-functions-durable) — the intended next-major replacement for Azure/azure-functions-durable-js v3.

The core helpers are clean, and reusing the existing execution path with an in-process capturing stub is a nice low-risk approach. The v3 compat adapters (context.df.* for orchestrations/entities and the client method surface) are genuinely broad and well documented.

My main concern is the "drop-in / run unchanged" framing in the README: this is a strong compatibility shim for the common method surface, but several heavily-used v3 patterns and the entire durable-client authoring model are not covered — and there's one silent-failure bug in the orchestrator adapter. Details are inline; grouped here:

Bug (please fix)

• wrapOrchestrator picks classic-vs-native by parameter arity, which silently mis-runs a native single-arg orchestrator (async function*(ctx)) — the body never executes and no error is thrown.

Behavioral breaks vs v3 (worth closing or documenting)

• createTimer returns a non-cancelable Task; the Task.any + timeoutTask.cancel() timeout pattern breaks, and the Task result shape changed (isCompleted/isFaulted/result → isComplete/isFailed/getResult()).
• Orchestration/entity contexts no longer extend InvocationContext.
• Missing top-level exports: DummyOrchestrationContext/DummyEntityContext (breaks users' tests), error types (DurableError/AggregatedError/TaskFailedError) for instanceof, ManagedIdentityTokenSource/TokenSource; the app.client.* durable-client trigger helpers and setExceptionPropertiesProvider are also gone.
• Client deltas: getStatus returns | undefined and ignores showHistory; createCheckStatusResponse now requires a defined request; startNew drops the version option.

Nits

• parseJson doesn't guard "" (JSON.parse("") throws).
• Core: a version-mismatch abandon makes processOrchestratorRequest throw a generic error.
• Spurious deserializeBinary reorder in the generated proto .d.ts.
• engines.node >= 22 vs @types/node@^18; the Node-22 floor is a notable consumer bump.

Overall a promising foundation — I'd fix the arity bug and soften/annotate the compatibility claims before this reads as a transparent v3 replacement. Leaving this as comments (non-blocking).