fix: tsconfig publish#11
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR enables the publication of the @temporal-contract/tsconfig package by removing the "private": true flag and adding version "0.0.2". The package provides shared TypeScript configuration files (base.json, common.json, sample.json) used across all packages and samples in the monorepo.
Key Changes:
- Removed "private": true flag to allow npm publication
- Added version "0.0.2" for initial public release
Comments suppressed due to low confidence (1)
tools/tsconfig/package.json:9
- The package.json is missing several standard fields that are present in other published @temporal-contract packages. Consider adding: "type": "module" for ESM support, "homepage", "bugs", "repository", "author", "license", and "keywords" fields to provide complete package metadata for npm publication.
{
"name": "@temporal-contract/tsconfig",
"version": "0.0.2",
"description": "Shared TypeScript configuration for temporal-contract packages",
"files": [
"base.json",
"common.json",
"sample.json"
]
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Contributor
Co-authored-by: btravers <3476441+btravers@users.noreply.github.com>
Add @temporal-contract/tsconfig to fixed versioning group
8 tasks
btravers
pushed a commit
that referenced
this pull request
May 5, 2026
…dError.cause as TemporalFailure The client side already does the right thing for parent-workflow failures — `classifyResultError` detects Temporal's `WorkflowFailedError` wrapper and forwards `error.cause` so consumers can match `err.cause` directly against `ApplicationFailure | CancelledFailure | TerminatedFailure | TimeoutFailure`. The worker side did not. Child-workflow `try/catch` blocks wrapped the raw exception as `ChildWorkflowError.cause`, so callers could not distinguish a `ChildWorkflowFailure → ApplicationFailure` from a cancellation without peeling two layers of wrappers. This commit closes the asymmetry: - New `classifyChildWorkflowError(operation, error, name)` helper in `packages/worker/src/internal.ts` mirrors `classifyResultError`. It detects cancellation via `@temporalio/workflow`'s `isCancellation` (which sees through nested `ChildWorkflowFailure → CancelledFailure` chains) and surfaces a new `ChildWorkflowCancelledError` discriminant. Otherwise, it unwraps `ChildWorkflowFailure.cause` so the actionable failure type reaches the consumer in one step. - The three `try/catch` blocks in `createTypedChildHandle.result`, `createStartChildWorkflow`, and `createExecuteChildWorkflow` now delegate to the helper, and their `ResultAsync` return types pick up the new `ChildWorkflowCancelledError` member of the union. - `WorkflowFailedError.cause` is re-typed from `unknown` to a new public `TemporalFailure` union (`ApplicationFailure | CancelledFailure | TerminatedFailure | TimeoutFailure | ChildWorkflowFailure | ServerFailure | ActivityFailure`) re-exported from the client entry point. The classify helpers cast at the boundary because Temporal's SDK types `cause` as `Error | undefined` despite only ever populating it with a leaf `TemporalFailure`. - Coverage: a new `child-workflow.spec.ts` exercises every classify branch (Application/Timeout/Terminated unwrap, both cancellation shapes, arbitrary errors, per-operation message phrasing). `errors.spec.ts` adds three `expectTypeOf` assertions locking the cause typing in. Closes audit findings #1 (worker child-workflow cause unwrapping) and #11 (WorkflowFailedError cause typing). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
btravers
pushed a commit
that referenced
this pull request
May 5, 2026
…dError.cause as TemporalFailure The client side already does the right thing for parent-workflow failures — `classifyResultError` detects Temporal's `WorkflowFailedError` wrapper and forwards `error.cause` so consumers can match `err.cause` directly against `ApplicationFailure | CancelledFailure | TerminatedFailure | TimeoutFailure`. The worker side did not. Child-workflow `try/catch` blocks wrapped the raw exception as `ChildWorkflowError.cause`, so callers could not distinguish a `ChildWorkflowFailure → ApplicationFailure` from a cancellation without peeling two layers of wrappers. This commit closes the asymmetry: - New `classifyChildWorkflowError(operation, error, name)` helper in `packages/worker/src/internal.ts` mirrors `classifyResultError`. It detects cancellation via `@temporalio/workflow`'s `isCancellation` (which sees through nested `ChildWorkflowFailure → CancelledFailure` chains) and surfaces a new `ChildWorkflowCancelledError` discriminant. Otherwise, it unwraps `ChildWorkflowFailure.cause` so the actionable failure type reaches the consumer in one step. - The three `try/catch` blocks in `createTypedChildHandle.result`, `createStartChildWorkflow`, and `createExecuteChildWorkflow` now delegate to the helper, and their `ResultAsync` return types pick up the new `ChildWorkflowCancelledError` member of the union. - `WorkflowFailedError.cause` is re-typed from `unknown` to a new public `TemporalFailure` union (`ApplicationFailure | CancelledFailure | TerminatedFailure | TimeoutFailure | ChildWorkflowFailure | ServerFailure | ActivityFailure`) re-exported from the client entry point. The classify helpers cast at the boundary because Temporal's SDK types `cause` as `Error | undefined` despite only ever populating it with a leaf `TemporalFailure`. - Coverage: a new `child-workflow.spec.ts` exercises every classify branch (Application/Timeout/Terminated unwrap, both cancellation shapes, arbitrary errors, per-operation message phrasing). `errors.spec.ts` adds three `expectTypeOf` assertions locking the cause typing in. Closes audit findings #1 (worker child-workflow cause unwrapping) and #11 (WorkflowFailedError cause typing). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.