@btravstack/temporal-worker 0.15.0 → 0.16.0

package/dist/index.cjs

@@ -151,7 +151,17 @@ const activityUnits = (host, observers, unit) => (invocation, next) => {
 *
 * The workflow id becomes the `traceId` — minted outside this process and steady
 * across every retry, so all attempts join up in a log. An activity with no
-* workflow falls back to the activity id.
+* workflow falls back to the activity id; `workflowExecution` is optional
+* because Temporal's own `Info` declares it so, "not set if the activity was
+* not started by a Workflow", which a worker polling a task queue never sees.
+*
+* **A REUSED workflow id merges its runs into one trace**, and that is the
+* trade rather than an oversight: Temporal allows an id again once the previous
+* execution closed, so `order-42` run twice is one `traceId` over two runs.
+* `runId` would separate them and is the wrong correlation for this transport —
+* server-minted, opaque, and not what an operator greps for. A deployment that
+* needs per-run traces gives its workflows unique ids, which is what a Schedule
+* already does.
 */
 const metaFor = () => {
 	const info = (0, _temporalio_activity.activityInfo)();

package/dist/index.mjs

@@ -150,7 +150,17 @@ const activityUnits = (host, observers, unit) => (invocation, next) => {
 *
 * The workflow id becomes the `traceId` — minted outside this process and steady
 * across every retry, so all attempts join up in a log. An activity with no
-* workflow falls back to the activity id.
+* workflow falls back to the activity id; `workflowExecution` is optional
+* because Temporal's own `Info` declares it so, "not set if the activity was
+* not started by a Workflow", which a worker polling a task queue never sees.
+*
+* **A REUSED workflow id merges its runs into one trace**, and that is the
+* trade rather than an oversight: Temporal allows an id again once the previous
+* execution closed, so `order-42` run twice is one `traceId` over two runs.
+* `runId` would separate them and is the wrong correlation for this transport —
+* server-minted, opaque, and not what an operator greps for. A deployment that
+* needs per-run traces gives its workflows unique ids, which is what a Schedule
+* already does.
 */
 const metaFor = () => {
 	const info = activityInfo();

package/dist/schedule.cjs

@@ -16,24 +16,29 @@ let _temporal_contract_client = require("@temporal-contract/client");
 * This recovers exactly that one error into an `update`. Every other error
 * stays on the channel, still typed.
 *
-* **`spec` is the only field reconciled**, and the rest of an existing
-* schedule is left as it stands. Two different reasons, and they are worth
-* telling apart:
+* **`spec`, the action's `workflowType` and `args`, and `policies` are
+* reconciled**; everything else about an existing schedule is left as it
+* stands.
 *
+* - **`args` and `workflowType` are written, and they are checked on the way
+*   through.** The typed handle's `update` validates the returned action's
+*   `args` against the named workflow's input schema before anything is
+*   persisted, and answers `WorkflowValidationError` — the same error `create`
+*   answers, already on this channel. So a deploy that changed what the
+*   workflow takes is either written or refused, never reported `"updated"`
+*   over a server still holding the old action. `workflowType` rides with them
+*   because it is what selects the schema those args are checked against.
 * - **`state` is deliberately preserved.** A schedule an operator paused stays
 *   paused across a deploy, because unpausing it is a decision a person made
 *   and a deploy is not the place to reverse it.
-* - **`args` and the rest of the action are preserved because this cannot
-*   reconcile them SAFELY.** `create` validates `args` against the workflow's
-*   input schema; the handle's `update` takes Temporal's own
-*   `ScheduleUpdateOptions` and validates nothing, so writing them here would
-*   push unvalidated input at the server through a door the typed client keeps
-*   shut. A deploy that changes what a schedule RUNS — its args, its workflow,
-*   its policies — should say so explicitly: delete the schedule and create it,
-*   or reach `getHandle(id).update(...)` directly and own the shape.
+* - **`memo`, `searchAttributes` and the action's own overrides are
+*   preserved**, because rebuilding the action wholesale means reproducing
+*   `create`'s own assembly here — the task queue off the contract, the search
+*   attribute translation, eight optional overrides — which is a copy that
+*   drifts. A deploy changing one of those deletes the schedule and creates it.
 *
-* So: after this call the schedule FIRES when the arguments say. What it fires
-* with is whatever it already fired with.
+* So: after this call the schedule FIRES when the arguments say, and RUNS what
+* they say.
 *
 * ```ts
 * await ensureSchedule(client.for(orderContract).schedule, "sweepStaleOrders", {
@@ -45,7 +50,13 @@ let _temporal_contract_client = require("@temporal-contract/client");
 */
 const ensureSchedule = (schedules, workflow, options) => schedules.create(workflow, options).map(() => "created").flatMapErrCases((matcher) => matcher.with(unthrown.P.tag(_temporal_contract_client.SCHEDULE_ALREADY_EXISTS_ERROR_TAG), () => schedules.getHandle(options.scheduleId).update((previous) => ({
 	...previous,
-	spec: options.spec
+	spec: options.spec,
+	action: {
+		...previous.action,
+		workflowType: workflow,
+		args: [options.args]
+	},
+	...options.policies === void 0 ? {} : { policies: options.policies }
 })).map(() => "updated")).with(unthrown.P.tag("@temporal-contract/WorkflowNotInContractError"), (error) => (0, unthrown.ErrAsync)(error)).with(unthrown.P.tag("@temporal-contract/WorkflowValidationError"), (error) => (0, unthrown.ErrAsync)(error)));
 //#endregion
 exports.ensureSchedule = ensureSchedule;

package/dist/schedule.d.cts

@@ -18,24 +18,29 @@ export type ScheduleOutcome = "created" | "updated";
  * This recovers exactly that one error into an `update`. Every other error
  * stays on the channel, still typed.
  *
- * **`spec` is the only field reconciled**, and the rest of an existing
- * schedule is left as it stands. Two different reasons, and they are worth
- * telling apart:
+ * **`spec`, the action's `workflowType` and `args`, and `policies` are
+ * reconciled**; everything else about an existing schedule is left as it
+ * stands.
  *
+ * - **`args` and `workflowType` are written, and they are checked on the way
+ *   through.** The typed handle's `update` validates the returned action's
+ *   `args` against the named workflow's input schema before anything is
+ *   persisted, and answers `WorkflowValidationError` — the same error `create`
+ *   answers, already on this channel. So a deploy that changed what the
+ *   workflow takes is either written or refused, never reported `"updated"`
+ *   over a server still holding the old action. `workflowType` rides with them
+ *   because it is what selects the schema those args are checked against.
  * - **`state` is deliberately preserved.** A schedule an operator paused stays
  *   paused across a deploy, because unpausing it is a decision a person made
  *   and a deploy is not the place to reverse it.
- * - **`args` and the rest of the action are preserved because this cannot
- *   reconcile them SAFELY.** `create` validates `args` against the workflow's
- *   input schema; the handle's `update` takes Temporal's own
- *   `ScheduleUpdateOptions` and validates nothing, so writing them here would
- *   push unvalidated input at the server through a door the typed client keeps
- *   shut. A deploy that changes what a schedule RUNS — its args, its workflow,
- *   its policies — should say so explicitly: delete the schedule and create it,
- *   or reach `getHandle(id).update(...)` directly and own the shape.
+ * - **`memo`, `searchAttributes` and the action's own overrides are
+ *   preserved**, because rebuilding the action wholesale means reproducing
+ *   `create`'s own assembly here — the task queue off the contract, the search
+ *   attribute translation, eight optional overrides — which is a copy that
+ *   drifts. A deploy changing one of those deletes the schedule and creates it.
  *
- * So: after this call the schedule FIRES when the arguments say. What it fires
- * with is whatever it already fired with.
+ * So: after this call the schedule FIRES when the arguments say, and RUNS what
+ * they say.
  *
  * ```ts
  * await ensureSchedule(client.for(orderContract).schedule, "sweepStaleOrders", {

package/dist/schedule.d.mts

@@ -18,24 +18,29 @@ export type ScheduleOutcome = "created" | "updated";
  * This recovers exactly that one error into an `update`. Every other error
  * stays on the channel, still typed.
  *
- * **`spec` is the only field reconciled**, and the rest of an existing
- * schedule is left as it stands. Two different reasons, and they are worth
- * telling apart:
+ * **`spec`, the action's `workflowType` and `args`, and `policies` are
+ * reconciled**; everything else about an existing schedule is left as it
+ * stands.
  *
+ * - **`args` and `workflowType` are written, and they are checked on the way
+ *   through.** The typed handle's `update` validates the returned action's
+ *   `args` against the named workflow's input schema before anything is
+ *   persisted, and answers `WorkflowValidationError` — the same error `create`
+ *   answers, already on this channel. So a deploy that changed what the
+ *   workflow takes is either written or refused, never reported `"updated"`
+ *   over a server still holding the old action. `workflowType` rides with them
+ *   because it is what selects the schema those args are checked against.
  * - **`state` is deliberately preserved.** A schedule an operator paused stays
  *   paused across a deploy, because unpausing it is a decision a person made
  *   and a deploy is not the place to reverse it.
- * - **`args` and the rest of the action are preserved because this cannot
- *   reconcile them SAFELY.** `create` validates `args` against the workflow's
- *   input schema; the handle's `update` takes Temporal's own
- *   `ScheduleUpdateOptions` and validates nothing, so writing them here would
- *   push unvalidated input at the server through a door the typed client keeps
- *   shut. A deploy that changes what a schedule RUNS — its args, its workflow,
- *   its policies — should say so explicitly: delete the schedule and create it,
- *   or reach `getHandle(id).update(...)` directly and own the shape.
+ * - **`memo`, `searchAttributes` and the action's own overrides are
+ *   preserved**, because rebuilding the action wholesale means reproducing
+ *   `create`'s own assembly here — the task queue off the contract, the search
+ *   attribute translation, eight optional overrides — which is a copy that
+ *   drifts. A deploy changing one of those deletes the schedule and creates it.
  *
- * So: after this call the schedule FIRES when the arguments say. What it fires
- * with is whatever it already fired with.
+ * So: after this call the schedule FIRES when the arguments say, and RUNS what
+ * they say.
  *
  * ```ts
  * await ensureSchedule(client.for(orderContract).schedule, "sweepStaleOrders", {

package/dist/schedule.mjs

@@ -15,24 +15,29 @@ import { SCHEDULE_ALREADY_EXISTS_ERROR_TAG } from "@temporal-contract/client";
 * This recovers exactly that one error into an `update`. Every other error
 * stays on the channel, still typed.
 *
-* **`spec` is the only field reconciled**, and the rest of an existing
-* schedule is left as it stands. Two different reasons, and they are worth
-* telling apart:
+* **`spec`, the action's `workflowType` and `args`, and `policies` are
+* reconciled**; everything else about an existing schedule is left as it
+* stands.
 *
+* - **`args` and `workflowType` are written, and they are checked on the way
+*   through.** The typed handle's `update` validates the returned action's
+*   `args` against the named workflow's input schema before anything is
+*   persisted, and answers `WorkflowValidationError` — the same error `create`
+*   answers, already on this channel. So a deploy that changed what the
+*   workflow takes is either written or refused, never reported `"updated"`
+*   over a server still holding the old action. `workflowType` rides with them
+*   because it is what selects the schema those args are checked against.
 * - **`state` is deliberately preserved.** A schedule an operator paused stays
 *   paused across a deploy, because unpausing it is a decision a person made
 *   and a deploy is not the place to reverse it.
-* - **`args` and the rest of the action are preserved because this cannot
-*   reconcile them SAFELY.** `create` validates `args` against the workflow's
-*   input schema; the handle's `update` takes Temporal's own
-*   `ScheduleUpdateOptions` and validates nothing, so writing them here would
-*   push unvalidated input at the server through a door the typed client keeps
-*   shut. A deploy that changes what a schedule RUNS — its args, its workflow,
-*   its policies — should say so explicitly: delete the schedule and create it,
-*   or reach `getHandle(id).update(...)` directly and own the shape.
+* - **`memo`, `searchAttributes` and the action's own overrides are
+*   preserved**, because rebuilding the action wholesale means reproducing
+*   `create`'s own assembly here — the task queue off the contract, the search
+*   attribute translation, eight optional overrides — which is a copy that
+*   drifts. A deploy changing one of those deletes the schedule and creates it.
 *
-* So: after this call the schedule FIRES when the arguments say. What it fires
-* with is whatever it already fired with.
+* So: after this call the schedule FIRES when the arguments say, and RUNS what
+* they say.
 *
 * ```ts
 * await ensureSchedule(client.for(orderContract).schedule, "sweepStaleOrders", {
@@ -44,7 +49,13 @@ import { SCHEDULE_ALREADY_EXISTS_ERROR_TAG } from "@temporal-contract/client";
 */
 const ensureSchedule = (schedules, workflow, options) => schedules.create(workflow, options).map(() => "created").flatMapErrCases((matcher) => matcher.with(P.tag(SCHEDULE_ALREADY_EXISTS_ERROR_TAG), () => schedules.getHandle(options.scheduleId).update((previous) => ({
 	...previous,
-	spec: options.spec
+	spec: options.spec,
+	action: {
+		...previous.action,
+		workflowType: workflow,
+		args: [options.args]
+	},
+	...options.policies === void 0 ? {} : { policies: options.policies }
 })).map(() => "updated")).with(P.tag("@temporal-contract/WorkflowNotInContractError"), (error) => ErrAsync(error)).with(P.tag("@temporal-contract/WorkflowValidationError"), (error) => ErrAsync(error)));
 //#endregion
 export { ensureSchedule };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@btravstack/temporal-worker",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "The Temporal worker runtime for @btravstack/core: one unit per activity attempt, and a drain that honours the kernel's deadline",
   "keywords": [
     "graceful-shutdown",
@@ -54,11 +54,11 @@
     }
   },
   "devDependencies": {
-    "@btravstack/config": "0.15.0",
-    "@btravstack/core": "0.15.0",
-    "@btravstack/di": "0.15.0",
+    "@btravstack/config": "0.16.0",
+    "@btravstack/core": "0.16.0",
+    "@btravstack/di": "0.16.0",
     "@btravstack/internal-test-infra": "0.0.0",
-    "@btravstack/testing": "0.15.0",
+    "@btravstack/testing": "0.16.0",
     "@btravstack/tsconfig": "0.4.0",
     "@temporal-contract/client": "8.0.0-beta.9",
     "@temporal-contract/contract": "8.0.0-beta.9",
@@ -78,9 +78,9 @@
     "zod": "4.5.4"
   },
   "peerDependencies": {
-    "@btravstack/config": "^0.15.0",
-    "@btravstack/core": "^0.15.0",
-    "@btravstack/di": "^0.15.0",
+    "@btravstack/config": "^0.16.0",
+    "@btravstack/core": "^0.16.0",
+    "@btravstack/di": "^0.16.0",
     "@temporal-contract/client": "^8.0.0-beta.9",
     "@temporal-contract/contract": "^8.0.0-beta.9",
     "@temporal-contract/worker": "^8.0.0-beta.9",