chore(deps): bump actions/checkout from 4 to 6#1
Merged
Conversation
Bumps [actions/checkout](https://github.com/actions/checkout) from 4 to 6. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v4...v6) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
deleted the
dependabot/github_actions/actions/checkout-6
branch
btravers
pushed a commit
that referenced
this pull request
May 4, 2026
…ckage scaffolding The previous accuracy pass fixed bugs but left real footguns undocumented. Adds the high-impact missing tribal knowledge identified in the audit. New rule files: - workflow-determinism.md — banned APIs (Date.now, Math.random, setTimeout, crypto, native I/O) and Temporal-provided replacements. Promoted to the #1 entry in AGENTS.md's top-rules list since determinism is the leading cause of broken Temporal workflows. - adding-a-package.md — step-by-step runbook covering tsconfig extension, vitest config, knip + changeset registration, peer-dep mirroring, and the multi-entry exports gotcha. Expanded existing files: - handlers.md: added Cancellation section (cancellableScope / nonCancellableScope / WorkflowCancelledError) and ApplicationFailure semantics (type / nonRetryable / cause / details), each with file:line breadcrumbs to the canonical source. - code-style.md: documented the three non-default tsconfig flags (noUncheckedIndexedAccess, exactOptionalPropertyTypes, noPropertyAccessFromIndexSignature) with the spread idiom for optional cause. Stated that oxlint enforces only two rules. - commands.md: listed all 11 commitlint-allowed types (config-conventional) with one-line guidance per type. - testing.md: added file:line breadcrumb to vitest.config.ts:11-27, noted contract package's unit-only template, documented turbo's cache: false on test tasks and the vitest --coverage flag passthrough. - project-overview.md: added repo-layout table (packages / examples / tools / docs), canonical entry-point breadcrumbs per package, and cross-links to determinism + handlers rules. Cleanup: - AGENTS.md: top-rules list grew from 5 to 6 with determinism at #1; rule-reference table now includes the two new files. - CONTRIBUTING.md: trimmed to a contributor on-ramp that delegates to .agents/rules/ as canonical, eliminating the prior duplication (commit types, code-style, test conventions). Adds a where-to-look table covering all nine rule files. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
btravers
pushed a commit
that referenced
this pull request
May 4, 2026
…ckage scaffolding The previous accuracy pass fixed bugs but left real footguns undocumented. Adds the high-impact missing tribal knowledge identified in the audit. New rule files: - workflow-determinism.md — banned APIs (Date.now, Math.random, setTimeout, crypto, native I/O) and Temporal-provided replacements. Promoted to the #1 entry in AGENTS.md's top-rules list since determinism is the leading cause of broken Temporal workflows. - adding-a-package.md — step-by-step runbook covering tsconfig extension, vitest config, knip + changeset registration, peer-dep mirroring, and the multi-entry exports gotcha. Expanded existing files: - handlers.md: added Cancellation section (cancellableScope / nonCancellableScope / WorkflowCancelledError) and ApplicationFailure semantics (type / nonRetryable / cause / details), each with file:line breadcrumbs to the canonical source. - code-style.md: documented the three non-default tsconfig flags (noUncheckedIndexedAccess, exactOptionalPropertyTypes, noPropertyAccessFromIndexSignature) with the spread idiom for optional cause. Stated that oxlint enforces only two rules. - commands.md: listed all 11 commitlint-allowed types (config-conventional) with one-line guidance per type. - testing.md: added file:line breadcrumb to vitest.config.ts:11-27, noted contract package's unit-only template, documented turbo's cache: false on test tasks and the vitest --coverage flag passthrough. - project-overview.md: added repo-layout table (packages / examples / tools / docs), canonical entry-point breadcrumbs per package, and cross-links to determinism + handlers rules. Cleanup: - AGENTS.md: top-rules list grew from 5 to 6 with determinism at #1; rule-reference table now includes the two new files. - CONTRIBUTING.md: trimmed to a contributor on-ramp that delegates to .agents/rules/ as canonical, eliminating the prior duplication (commit types, code-style, test conventions). Adds a where-to-look table covering all nine rule files. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
btravers
pushed a commit
that referenced
this pull request
May 5, 2026
… cancellation scopes Two related bugs in the worker's neverthrow integration: 1. Five `new ResultAsync(work())` call sites — three in workflow.ts (createTypedChildHandle.result, createStartChildWorkflow, createExecuteChildWorkflow) and two in cancellation.ts (cancellableScope, nonCancellableScope) — failed to catch rejections from `work()`. The ResultAsync constructor does not wrap; if the work function throws synchronously or returns a rejected promise, the resulting ResultAsync rejects, escaping neverthrow's railway as an unhandled rejection rather than landing on the typed err(...) channel callers actually inspect. 2. Both cancellation-scope helpers re-threw non-cancellation errors inside their work bodies via `throw error`. Combined with bug #1 that meant any domain failure thrown inside a cancellable or non-cancellable scope leaked as an unhandled rejection — the scope helpers' typed err(...) channel only ever surfaced WorkflowCancelledError. Fixes: - Hoist the `_internal_makeResultAsync` helper to @temporal-contract/contract so client and worker share one implementation. The helper takes a `mapRejection` callback so each consumer routes rejections to its own typed error class. neverthrow is now a peer dep (+ matching dev dep) on contract since it appears in the helper's public types. The helper is exported under a deliberately-internal-looking name so it is not part of the public API surface. - Update client/src/internal.ts to delegate to the shared helper so the existing client-side wrapper keeps its `RuntimeClientError` fallback unchanged. - Add WorkflowScopeError to packages/worker/src/errors.ts (re-exported from the worker/workflow barrel). cancellableScope and nonCancellableScope now return ResultAsync<T, WorkflowCancelledError | WorkflowScopeError>: the cancellation branch is unchanged, non-cancellation throws surface as err(WorkflowScopeError) with the original error preserved on `cause`. Callers branch with `instanceof` to discriminate the two. - Replace the five `new ResultAsync(work())` sites with the helper. The workflow.ts work bodies already produce typed `Result<T, ChildWorkflowError>`, so the helper's catch is a strict safety net — but the cancellation-scope sites now genuinely route errors through it. - Update cancellation.spec.ts: the previous "propagates non-cancellation errors as Future rejections" test now asserts err(WorkflowScopeError) with `cause` preserved. Add coverage for the synchronous-throw safety path. - Add direct unit coverage for `_internal_makeResultAsync` in the contract package (resolved ok / err pass-through / rejected promise via mapRejection / synchronous throw before first await / non-Error-throwable forwarded to mapRejection). The agent rule at .agents/rules/handlers.md:92-95 still claims "non-cancellation errors propagate as ResultAsync rejections" and is now stale — to be updated in a follow-up to keep this PR's scope tight. Closes audit findings #5 (unhandled rejections in workflow.ts and cancellation.ts) and #6 (cancellation-scope error channel incompleteness). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
btravers
pushed a commit
that referenced
this pull request
May 5, 2026
… cancellation scopes Two related bugs in the worker's neverthrow integration: 1. Five `new ResultAsync(work())` call sites — three in workflow.ts (createTypedChildHandle.result, createStartChildWorkflow, createExecuteChildWorkflow) and two in cancellation.ts (cancellableScope, nonCancellableScope) — failed to catch rejections from `work()`. The ResultAsync constructor does not wrap; if the work function throws synchronously or returns a rejected promise, the resulting ResultAsync rejects, escaping neverthrow's railway as an unhandled rejection rather than landing on the typed err(...) channel callers actually inspect. 2. Both cancellation-scope helpers re-threw non-cancellation errors inside their work bodies via `throw error`. Combined with bug #1 that meant any domain failure thrown inside a cancellable or non-cancellable scope leaked as an unhandled rejection — the scope helpers' typed err(...) channel only ever surfaced WorkflowCancelledError. Fixes: - Hoist the `_internal_makeResultAsync` helper to @temporal-contract/contract so client and worker share one implementation. The helper takes a `mapRejection` callback so each consumer routes rejections to its own typed error class. neverthrow is now a peer dep (+ matching dev dep) on contract since it appears in the helper's public types. The helper is exported under a deliberately-internal-looking name so it is not part of the public API surface. - Update client/src/internal.ts to delegate to the shared helper so the existing client-side wrapper keeps its `RuntimeClientError` fallback unchanged. - Add WorkflowScopeError to packages/worker/src/errors.ts (re-exported from the worker/workflow barrel). cancellableScope and nonCancellableScope now return ResultAsync<T, WorkflowCancelledError | WorkflowScopeError>: the cancellation branch is unchanged, non-cancellation throws surface as err(WorkflowScopeError) with the original error preserved on `cause`. Callers branch with `instanceof` to discriminate the two. - Replace the five `new ResultAsync(work())` sites with the helper. The workflow.ts work bodies already produce typed `Result<T, ChildWorkflowError>`, so the helper's catch is a strict safety net — but the cancellation-scope sites now genuinely route errors through it. - Update cancellation.spec.ts: the previous "propagates non-cancellation errors as Future rejections" test now asserts err(WorkflowScopeError) with `cause` preserved. Add coverage for the synchronous-throw safety path. - Add direct unit coverage for `_internal_makeResultAsync` in the contract package (resolved ok / err pass-through / rejected promise via mapRejection / synchronous throw before first await / non-Error-throwable forwarded to mapRejection). The agent rule at .agents/rules/handlers.md:92-95 still claims "non-cancellation errors propagate as ResultAsync rejections" and is now stale — to be updated in a follow-up to keep this PR's scope tight. Closes audit findings #5 (unhandled rejections in workflow.ts and cancellation.ts) and #6 (cancellation-scope error channel incompleteness). 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
1 participant
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.
Bumps actions/checkout from 4 to 6.
Release notes
Sourced from actions/checkout's releases.
... (truncated)
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
8e8c483Clarify v6 README (#2328)033fa0dAdd worktree support for persist-credentials includeIf (#2327)c2d88d3Update all references from v5 and v4 to v6 (#2314)1af3b93update readme/changelog for v6 (#2311)71cf226v6-beta (#2298)069c695Persist creds to a separate file (#2286)ff7abcdUpdate README to include Node.js 24 support details and requirements (#2248)08c6903Prepare v5.0.0 release (#2238)9f26565Update actions checkout to use node 24 (#2226)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)