You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Phase 3 of the friendlier-errors stack. Also folds in #1812 so that PR can close as superseded.
Structured logger child API.runtimeLogger / stepLogger / webhookLogger etc. now expose .child(metadata) and .forRun(runId, workflowName, extra?), so runtime and step handlers don't have to repeat workflowRunId / workflowName / stepId on every log call.
Normalized error metadata. Ad-hoc error: err.message strings are replaced with structured errorName / errorMessage / errorStack fields so log drains can render and group them properly.
Comments on silent catches. The EntityConflictError / RunExpiredError paths that swallow expected idempotency conflicts now explain why it's safe to drop the error.
Split replay-timeout into warn-while-retrying vs. error-when-giving-up, and surface the underlying error when we can't mark a timed-out run as failed.
Include error stacks in the "Fatal runtime error during workflow setup" log and the top-level user-code workflow error log so the stack surfaces in flattened drains.
Drop the [Workflows] "<runId>" - prefix from buildWorkflowSuspensionMessage — the structured logger attaches run context now.
All tests below use workbench/nextjs-turbopack. Start with cd workbench/nextjs-turbopack && pnpm dev and watch the terminal.
Console prefix — trigger any workflow. Every log line should begin with [workflow-sdk]. Search logs for \[Workflows\] — should be zero hits (the old prefix is gone).
Structured run/step context — inspect any step log line. It should carry runId, workflowName, stepId as structured metadata (the object after the message), not interpolated into the message string.
Error stacks in logs — deliberately throw from a step:
Run the workflow. Confirm the full stack is the log message (survives flattened drains like Axiom/Datadog), not relegated to a structured field.
Structured error fields — at step-failure / run-failure, confirm errorName, errorMessage, and errorStack appear as structured metadata fields (in addition to the stack in the message).
Replay-timeout warn vs. error — set WORKFLOW_REPLAY_TIMEOUT_MS=50 in env and run a workflow with any non-trivial work. On early replay attempts expect a warn-level line ("replay timed out, retrying"); after retries exhaust expect an error-level line with the underlying failure cause visible.
Fatal setup error includes stack — if you can induce a fatal-at-setup (e.g. by crashing a worker init path), the "Fatal runtime error during workflow setup" log should include the full stack.
Suspension message has no legacy prefix — trigger a workflow that awaits a hook and suspends. The suspension log line should NOT start with [Workflows] "<runId>" - — only [workflow-sdk], with run context in structured metadata.
Idempotency conflicts are silently dropped — hard to induce deliberately; verify by reading the commented catches (EntityConflictError / RunExpiredError) around idempotent step-completion paths. No user-visible test.
Unit tests
New src/logger.test.ts covers .child, .forRun, metadata merging, and conflict precedence (10 tests).
Existing src/util.test.ts updated for new suspension-message format (23 tests pass).
pnpm typecheck reports no new errors.
📚 Friendlier errors stack
Multi-PR initiative inspired by @Schniz's stalled #706:
Adds a `.child()` and `.forRun(runId, workflowName)` child-logger API to
the structured logger so runtime/step code doesn't have to repeat
`workflowRunId`/`workflowName`/`stepId` on every call. Normalizes error
metadata to structured `errorName` / `errorMessage` / `errorStack` fields
instead of ad-hoc `error: err.message` strings, and adds comments to
silent catches that swallow expected idempotency conflicts.
Also folds in the pending changes from #1812 so that PR can be closed:
- Standardize the console prefix to `[workflow-sdk]`.
- Split the replay-timeout log into a warn-while-retrying vs.
error-when-giving-up, and surface the underlying error when we can't
mark a timed-out run as failed.
- Include the error stack in the "Fatal runtime error during workflow
setup" log and in the top-level user-code workflow error log so the
stack surfaces in flattened log drains.
- Drop the `[Workflows] "<runId>" - ` prefix from
`buildWorkflowSuspensionMessage` — the structured logger now attaches
run context.
Supersedes #1812.
Co-Authored-By: Claude Opus 4.7 <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
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.
Summary
Phase 3 of the friendlier-errors stack. Also folds in #1812 so that PR can close as superseded.
runtimeLogger/stepLogger/webhookLoggeretc. now expose.child(metadata)and.forRun(runId, workflowName, extra?), so runtime and step handlers don't have to repeatworkflowRunId/workflowName/stepIdon every log call.error: err.messagestrings are replaced with structurederrorName/errorMessage/errorStackfields so log drains can render and group them properly.EntityConflictError/RunExpiredErrorpaths that swallow expected idempotency conflicts now explain why it's safe to drop the error.Folded in from #1812 (supersedes it)
[workflow-sdk].[Workflows] "<runId>" -prefix frombuildWorkflowSuspensionMessage— the structured logger attaches run context now.Closes / supersedes:#1812
Manual test plan
All tests below use
workbench/nextjs-turbopack. Start withcd workbench/nextjs-turbopack && pnpm devand watch the terminal.[workflow-sdk]. Search logs for\[Workflows\]— should be zero hits (the old prefix is gone).runId,workflowName,stepIdas structured metadata (the object after the message), not interpolated into the message string.errorName,errorMessage, anderrorStackappear as structured metadata fields (in addition to the stack in the message).WORKFLOW_REPLAY_TIMEOUT_MS=50in env and run a workflow with any non-trivial work. On early replay attempts expect awarn-level line ("replay timed out, retrying"); after retries exhaust expect anerror-level line with the underlying failure cause visible.[Workflows] "<runId>" -— only[workflow-sdk], with run context in structured metadata.EntityConflictError/RunExpiredError) around idempotent step-completion paths. No user-visible test.Unit tests
src/logger.test.tscovers.child,.forRun, metadata merging, and conflict precedence (10 tests).src/util.test.tsupdated for new suspension-message format (23 tests pass).pnpm typecheckreports no new errors.📚 Friendlier errors stack
Multi-PR initiative inspired by @Schniz's stalled #706:
Ansirendering primitives + context-violation errorsSerializationErrorat serialization / stream / encryption boundariesdescribeError)throw new Error(...)sitesdescribeRunError+ public subpathWorkflowBuildError+ applications in@workflow/buildersfunctionNameleak, simplify docs framing, redirect stack to user codeEach PR is stacked on the previous one; merge in order.
🤖 Generated with Claude Code