Releases: temporalio/sdk-typescript
1.7.1
1.7.0
Features
-
💥 [
worker
] The experimentalWorker.runReplayHistories
method, which allows efficient replay of a large number
of workflow histories, now returns anAsyncIterableIterator
(#1067)EXAMPLE USAGE
const histories = client.workflow.list({ query: 'WorkflowType="MyWorkflow"' }).intoHistories({ concurrency: 10 }); const replayResults = Worker.runReplayHistories( { workflowsPath: require.resolve('./workflows'), // ... }, histories ); for await (const result of replayResults) { const { workflowId, runId, error } = result; // error is either undefined, a ReplayError, or a DeterminismViolationError }
-
💥 [
worker
]WorkerOptions.shutdownGraceTime
no longer forcefully shuts the worker down. Now, whenshutdownGraceTime
passes, the worker just sends Cancellation to running Activities.
SetWorkerOptions.shutdownForceTime
to force shutdown. (#1072) -
💥 [
testing
] Use Temporal CLI to power local test environment (#1077)
Bug Fixes
-
Fail Workflow on
WorkflowExecutionAlreadyStartedError
(#1068) -
[
create-project
] While fixing dependencies on a newly instantiated project, we now recursively search for
package.json and tsconfig.json (#1089 thanks to@jhubbardsf
🙏) -
[
create-project
] Remove the.post-create
file (if it exists), before committing to git (#1018) -
💥 Completetly removed support for Node versions <= 14.17. Lot of our dependencies were already
requiring Node 14.18+ anyway. (#1070) -
Load package
abort-controller
as a polyfill rather than a complete substitution.
This will ensure using native implementation of that class in Node 16+ (#1070)💥 This change might cause TypeScript to warn about incompatible types when working with libraries that are using
custom type definitions for theAbortSignal
interface.import type { AbortSignal as FetchAbortSignal } from 'node-fetch/externals'; // ... const response = await fetch(url, { signal: Context.current().cancellationSignal as FetchAbortSignal });
-
[
client
] Get rid of experimentalAsyncLocalStorage.enterWith
call (#1080) -
[
core
] Fix slot metrics appearing to be off-by-one because of reservation (#479) -
[
core
] Fix misnamed metricworkflow_task_execution_failed
(#481) -
[
core
] Added an internal patching mechanism for adjusting SDK behavior based on what version of the SDK has previously processed the workflow. Note that this new mechanism requires server Temporal 1.20.0 or above. Any change that depends on such an internal patch will not be effective with older servers. (#482) -
💥 [
core
] Make activity (and child workflow) type / id mismatches will results in a non-deterministic change. That means that renaming an activity or a child workflow will now require a patch. Note that this change has been gated with an internal patch to avoid suddently failing with nondeterminism errors on older activity rename (see details above) (#475, #482) -
[
core
] Auto-fail new workflow tasks which encounter a problem upon their application, but before any activation has been issued to lang. This may fix some scenarios where previously a WFT would simply time out. (#482)
Documentation
- Add install protocal buffers step to CONTRIBUTING.md doc (#1086, thanks to
@jhubbardsf
🙏)
1.6.0
Features
-
[
workflow
] (Experimental) Introduced a major optimization to the workflow runtime (#951).This optimization allows the worker to reuse execution context across workflows, without compromising the safety of the deterministic sandbox. Some initial performance tests have demonstrated reduction of RAM usage by as much as 66%, and reduction of CPU usage by up to 50%.
To enable this feature, add
reuseV8Context: true
to yourWorkerOptions
. -
[
workflow
] AddedworkflowInfo().startTime
andworkflowInfo().runStartTime
. (#1031) -
[
workflow
] Added support for default workflow handlers (#1038).A workflow bundle may opt-in to receive requests for non-registered workflow types by exporting a default function:
export default async function (...args: unknown[]): Promise<unknown> { const { workflowType } = workflowInfo(); // ... }
-
[
workflow
] Added support for default signal handlers (#1038).A workflow function may opt-in to receive requests for non-registered signals with:
setDefaultSignalHandler((signalName: string, ...args: unknown[]) => { // ... });
-
[
worker
] It is now possible to launch workers in debug mode by setting environment variableTEMPORAL_DEBUG=true
(#1031).
Bug Fixes
-
A recent release of
@grpc/grpc-js
has been causing multiple issues:- 10 seconds timeout on process exit,
- process crashing unexplainedly,
- "Failed to connect before deadline" errors, and more.
We pinned our dependencies on
@grpc/grpc-js
to1.7.3
(#1025). This pin will be removed once we confirm that the upstream project is stable again for our usage. -
[
client
] Multiple small changes to the experimental Schedules API. (#1028, #1032, #1009) -
[
workflow
]instanceof
onWorkflowInfo
fields now works as expected (#1031, #659) -
[
create-project
]create-project
now works correctly on Node 18 (#995) -
[
core
] Fixed incorrect calculation of schedule-to-start timeouts on local activities (#450). -
[
core
] Fixed some rare case where sdk-core would panic on unexpected history fetching responses from the server (#468). -
[
core
] Fixed some rare case where an activation completion might get blocked if fetching history pages failed (#478).
1.5.2
1.5.0
Features
-
[
client
] The experimentalWorkflowHandle.fetchHistory
function can now be used to easily obtain a single
Workflow execution's history (#974). -
[
client
] Introduced (experimental) high level API to list workflows (#942,
#974):for await (const workflowInfo of client.workflow.list({ query: 'WorkflowType="MySuperCoolWorkflow"' })) { console.log(`${workflowInfo.workflowId} ${workflowInfo.runId}`); }
The same API can also be used to efficiently obtain a list of workflows histories. Multiple histories are fetched from
the server in parallel (up toconcurrency
, defaults to 5), which may improve performances.for await (const { workflowId, history } of client.workflow.list().intoHistories({ concurrency: 10 })) { // ... }
-
[
client
] Added (experimental) high level API to work with Schedules (#937,
#960):// Define a schedule that will start workflow 'RefreshClientTableWorkflow` every day at 5 AM and 1 PM await client.schedule.create({ scheduleId: `refresh-client-table-every-morning`, spec: { calendars: [{ hour: [5, 13] }], }, action: { type: 'startWorkflow', workflowType: 'RefreshClientTableWorkflow', taskQueue, }, });
Note that Schedules requires Temporal version 1.18 or later.
-
[
core
] Core's (experimental) telemetry options are now more configurable (#963,
#977). Notably, filters can now be specified independently
forlogging
(applicable to bothconsole
andforward
loggers) andtracing
. FunctionmakeTelemetryFilterString
can be used to easily build filter strings. Also, OTel metrics export interval can now be modified (defaults to 1
second).Note: the
TelemetryOptions
interface has changed quite a bit. Using appropriate new options is highly recommended.
Backward compatibility for legacy options is provided, to the extent possible, but these legacy options have been
deprecated. -
[
client
] WorkflowClient now supports a simpler way to define interceptors (#956).
Interceptors should now be provided as an array of interceptor object, rather than an array of factory to those
objects under a field namedcalls
. Former definition syntax is still supported, though deprecated.BEFORE
interceptors: { calls: [ (workflowId) => { create(...) => { ... } } ] }
AFTER
interceptors: [ { create(...) => { ... } } ]
-
[
worker
] Introduced an experimental API to efficiently replay a large number of workflow histories. Teams may
notably use this API to validate that changes to their workflow code will not cause non-determinism errors on existing
workflow instances, before rolling out these changes to production (#920,
#974).EXAMPLE USAGE
const histories = client.workflow.list({ query: 'WorkflowType="MyWorkflow"' }).intoHistories({ concurrency: 10 }); const replayResults = await Worker.runReplayHistories( { workflowsPath: require.resolve('./workflows'), // ... }, histories ); console.log(`Found ${replayResults.errors.length} replay errors`);
-
Added
activity_task_received
metric (#439)
Bug Fixes
-
[
workflow
] Don't fail workflow task if a query handler was not found (#932). -
[
worker
] Wait for worker shutdown ifrunUntil
promise throws (#943).
Previously,Worker.runUntil
would not wait for worker to complete its shutdown if the innerfnOrPromise
threw an
error. Now, it will always wait for both worker shutdown AND the innerfnOrPromise
to resolve. If either one throw
an error, then that error is rethrown. If both throw an error, aCombinedWorkerRunError
will be thrown instead,
with acause
attribute containing both errors. -
The (experimental)
FailureConverter
type now receives itsPayloadConverter
through an argument on convertion
methods, rather than through an option supplied at construction time (#936).
This provides a more predictable behaviour in the common case of using the default failure converter. More over,
FailureConverter.errorToFailure
function's return type has been lossen, so that it supports greater customization on
user side (#927) -
[
client
]ConnectionOptions.connectTimeout
is now being applied correctly (#954). -
[
workflow
] Properly encode memos inmakeContinueAsNewFunc
(#955).
They were previously not encoded at all, resulting in a failure due to invalid data. -
[
worker
] Activity metricscheduled_to_start_latency
now reports the time from the schedule time of the
current attempt to the start time of that same attempt, instead of the time elapsed since the initial schedule time
(#975). This new definition aligns with other SDKs and is
more useful from a monitoring perspective. -
[
workflow
] Previously,condition(fn, 0)
was incorrectly handled the same ascondition(fn)
, meaning that the
function would block indefinitely and would return nothing oncefn
evaluated to true. It now behaves the same as
condition(fn, 1)
, ie. the function will sleep for a very short time, then return true iffn
evaluates to true,
or false if timeout reaches its expiration (#985). -
[
core
] Fixed some non-deterministic behaviour in workflows containing local activities, due to heartbeats
being incorrectly counted as logical workflow tasks (#987). -
[
core
]core-bridge
has been refactored so that it does not retain static references to custom TypeScript error
constructors (#983). This change is part of an ongoing effort
to resolve multiple issues observed by some users in execution of their unit tests based on sdk-typescript, notably in
conjunction with Jest, Mocha and Vitest. -
[
worker
] The default log function now write errors usingprocess.stderr.write
rather thanconsole.error
(#940). This avoids complains by some test runners. -
[
debugger
] Log errors comming from VS Code debugger (#968) -
Bug Fixes in Core SDK:
- Fixed a situation causing Core to send activations containing both a legacy query and other jobs (#427)
- Don't use a process-wide unique id for sticky queues (#430)
- Added support for ignorable history events (#422)
- Avoid hang in duplicated run-ids during replay (#417)
- Backoff more if we receive ResourceExhausted error (#408)
Miscellaneous Tasks
1.4.4
Bug Fixes
-
Don't request eager activities when worker started with no remote activities
Actual fix made in this Core SDK PR: temporalio/sdk-core#429
1.4.3
Bug Fixes
- [
nyc-test-coverage
] Delay checking for coverage until helpers run because coverage is undefined when Jest
starts (#910) - [
worker
] Avoid a race in shutdown hooks (#918) - [
core
] Ignore cancels of StartFailed state in child workflows, see: temporalio/sdk-core#413
1.3.1
1.4.2
1.4.1
Bug Fixes
-
[
client
] Handle test server empty history when waiting for workflow result
(#902) -
[
common
] Export and deprecate error helpers (#901)Fixes a breaking change accidentally introduces in 1.4.0 where some rarely used utility functions were deleted.
Miscellaneous Tasks
-
Improve regex for extracting source map (#899)
Addresses reported issue by userr where regex caused
RangeError: Maximum call stack size exceeded
when parsing their
workflow bundle.