fix: await worker startup readiness

[wangbill (YunchuWang)]

Summary

• make await worker.start() resolve after startup metadata is generated, the hello handshake succeeds, and the initial work-item stream is created with all handlers attached
• add a configurable 30-second startupTimeoutMs budget for metadata generation and hello, with gRPC deadline/cancellation
• cleanly abort failed or stopped startup attempts while preserving automatic stream reconnection after readiness
• expose startupTimeout() through the Azure-managed worker builder and document the new semantics

Breaking change

Previously, await worker.start() resolved before the sidecar was connected and retried forever in the background. It now rejects when the sidecar cannot be reached within startupTimeoutMs (30 seconds by default). Deployments where the worker can start before its sidecar should increase the timeout or retry startup from the caller:

for (;;) {
  try {
    await worker.start();
    break;
  } catch {
    await new Promise((resolve) => setTimeout(resolve, 1000));
  }
}

Fixes #69

Validation

• Full core suite: 70 suites / 1,251 tests passed
• npm test -w @microsoft/durabletask-js -- --runTestsByPath test/worker-startup.spec.ts test/worker-stream-recovery.spec.ts test/worker-unhandled-rejection.spec.ts — 3 suites / 26 tests passed
• npm test -w @microsoft/durabletask-js-azuremanaged -- --runTestsByPath test/unit/worker-builder.spec.ts — 1 suite / 7 tests passed
• npm run build:core && npm run build:azuremanaged
• targeted ESLint and Prettier checks for all PR-touched files
• workflow YAML parse and git diff --check
• dedicated worker recovery E2E job exercises startup with the emulator initially unavailable

[Copilot]

Pull request overview

This PR changes TaskHubGrpcWorker.start() semantics so that awaiting startup only resolves after the sidecar “hello” handshake succeeds and the initial work-item stream is confirmed ready, with a configurable startup timeout budget (default 30s). It also wires the new timeout knob through the Azure-managed worker builder and updates docs/changelogs accordingly.

Changes:

• Make await worker.start() wait for hello + initial work-item stream readiness, with a bounded startupTimeoutMs covering metadata generation, hello, and stream readiness.
• Add comprehensive unit tests for startup timing, cancellation, late callbacks, and stream recovery behavior.
• Expose .startupTimeout(milliseconds) on DurableTaskAzureManagedWorkerBuilder and document the new startup semantics.

Reviewed changes

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

Show a summary per file

File	Description
README.md	Documents new start() readiness semantics and builder timeout configuration.
CHANGELOG.md	Notes the core worker startup behavior change.
packages/durabletask-js/src/worker/task-hub-grpc-worker.ts	Implements startup readiness gating, startup timeout budget, and generation-based cancellation/cleanup.
packages/durabletask-js/test/worker-startup.spec.ts	Adds focused tests covering startup readiness, timeouts, stop-during-start, and late callbacks.
packages/durabletask-js/test/worker-stream-recovery.spec.ts	Adjusts mocks to account for metadata-based “stream ready” detection.
packages/durabletask-js-azuremanaged/src/worker-builder.ts	Adds .startupTimeout() builder method and passes it into core worker options.
packages/durabletask-js-azuremanaged/test/unit/worker-builder.spec.ts	Verifies builder propagates startup timeout to the core worker instance.
packages/durabletask-js-azuremanaged/README.md	Documents startup readiness and builder timeout configuration.
packages/durabletask-js-azuremanaged/CHANGELOG.md	Notes the new builder API for startup timeout configuration.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

Suppressed comments (2)

packages/durabletask-js/src/worker/task-hub-grpc-worker.ts:425

• The start() @throws doc is too narrow: start() can now throw TimeoutError for metadata generation and work-item stream establishment timeouts as well, not only the hello handshake.

   * @throws {@link TimeoutError} if the hello handshake exceeds `startupTimeoutMs`.

packages/durabletask-js/src/worker/task-hub-grpc-worker.ts:71

• The TaskHubGrpcWorkerOptions.startupTimeoutMs doc comment no longer matches behavior: the timeout budget is also applied to work-item stream metadata generation and establishing the initial stream, not just hello/metadata. Updating the comment helps avoid confusing API consumers.

  /**
   * Optional timeout in milliseconds for initial metadata generation and the sidecar hello handshake.
   * Defaults to 30000.
   */
  startupTimeoutMs?: number;

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.

[wangbill (YunchuWang)]

why this tests is separate