eve 0.38.0 → 0.38.2

package/dist/src/compiled/@workflow/world/queue.d.ts

@@ -67,6 +67,29 @@ export type RunInput = z.infer<typeof RunInputSchema>;
  * `events.create`, so both server receipts hash to the same digest under the
  * `(runId, resumeId)` constraint.
  */
+/**
+ * Resilient step dispatch data carried through the queue alongside a
+ * step-execution message ({@link WorkflowInvokePayload.stepId}). Present when
+ * the producer (the suspension handler dispatching a newly created step)
+ * parallelized the `step_created` event write with the queue publish — the
+ * same shape as resilient start (`runInput`) and the resilient hook resume
+ * (`hookInput`).
+ *
+ * When the producer's `step_created` write fails transiently (429 / 5xx /
+ * transport), the step entity may not exist when this message is consumed. A
+ * consumer that understands `stepInput` idempotently re-ensures the
+ * `step_created` event — keyed by the message's `stepId` (the step's
+ * correlation id, unique per `(runId, correlationId)`) — before executing, so
+ * the producer's write and the consumer's re-ensure converge on exactly one
+ * event.
+ *
+ * The `input` is the already-serialized (and possibly encrypted) step input —
+ * the identical bytes the producer also sent on the direct `events.create`.
+ */
+export declare const StepDispatchInputSchema: z.ZodObject<{
+    input: z.ZodCustom<Uint8Array<ArrayBufferLike>, Uint8Array<ArrayBufferLike>>;
+}, z.core.$strip>;
+export type StepDispatchInput = z.infer<typeof StepDispatchInputSchema>;
 export declare const HookResumeInputSchema: z.ZodObject<{
     resumeId: z.ZodString;
     hookId: z.ZodString;
@@ -76,6 +99,45 @@ export declare const HookResumeInputSchema: z.ZodObject<{
     deploymentId: z.ZodOptional<z.ZodString>;
 }, z.core.$strip>;
 export type HookResumeInput = z.infer<typeof HookResumeInputSchema>;
+/**
+ * Wall-clock boundaries of a hook-triggered resume, carried on the queue
+ * message so the SDK can report end-to-end time-to-resume (TTR) — entry into
+ * `resumeHook()` through to the first line of the next durable step — and its
+ * non-overlapping phase breakdown, as span attributes on that step's
+ * `step.execute` span. See `runtime/resume-latency.ts` in `@workflow/core`.
+ *
+ * Two groups of fields:
+ *
+ * - Producer fields (`resumeRequestedAtMs`, `queuePublishRequestedAtMs`,
+ *   `strategy`) are stamped by `resumeHook()` on the invocation message. They
+ *   ride along on a deployment-affinity re-route unchanged, so a misrouted
+ *   delivery's extra hop stays inside `queue_delivery`.
+ * - Consumer fields (`consumerStartedAtMs`, `replayStartedAtMs`,
+ *   `nextStepEncounteredAtMs`, `setupSource`) are filled in by the invocation
+ *   that replayed the resume, and ONLY when it dispatches the next durable
+ *   step to a separate queue invocation instead of running it inline. They let
+ *   that invocation report the same single TTR measurement.
+ *
+ * Every field is advisory and the whole object is optional, in all three
+ * directions that matter for a rolling deploy: a new producer's timing is
+ * ignored by an old consumer, a new consumer simply reports no TTR for an old
+ * message, and workflow-server never reads it at all.
+ *
+ * `strategy` and `setupSource` are deliberately typed as plain strings rather
+ * than enums: an unrecognized value from a newer producer must not fail the
+ * parse of the whole invocation payload (which would wedge the run) — it is
+ * only ever forwarded to a span attribute.
+ */
+export declare const HookResumeTimingSchema: z.ZodObject<{
+    resumeRequestedAtMs: z.ZodNumber;
+    queuePublishRequestedAtMs: z.ZodNumber;
+    strategy: z.ZodOptional<z.ZodString>;
+    consumerStartedAtMs: z.ZodOptional<z.ZodNumber>;
+    replayStartedAtMs: z.ZodOptional<z.ZodNumber>;
+    nextStepEncounteredAtMs: z.ZodOptional<z.ZodNumber>;
+    setupSource: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>;
+export type HookResumeTiming = z.infer<typeof HookResumeTimingSchema>;
 export declare const WorkflowInvokePayloadSchema: z.ZodObject<{
     runId: z.ZodString;
     traceCarrier: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
@@ -107,6 +169,18 @@ export declare const WorkflowInvokePayloadSchema: z.ZodObject<{
         payloadDigest: z.ZodString;
         deploymentId: z.ZodOptional<z.ZodString>;
     }, z.core.$strip>>;
+    stepInput: z.ZodOptional<z.ZodObject<{
+        input: z.ZodCustom<Uint8Array<ArrayBufferLike>, Uint8Array<ArrayBufferLike>>;
+    }, z.core.$strip>>;
+    hookResumeTiming: z.ZodCatch<z.ZodOptional<z.ZodObject<{
+        resumeRequestedAtMs: z.ZodNumber;
+        queuePublishRequestedAtMs: z.ZodNumber;
+        strategy: z.ZodOptional<z.ZodString>;
+        consumerStartedAtMs: z.ZodOptional<z.ZodNumber>;
+        replayStartedAtMs: z.ZodOptional<z.ZodNumber>;
+        nextStepEncounteredAtMs: z.ZodOptional<z.ZodNumber>;
+        setupSource: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>>>;
 }, z.core.$strip>;
 export type WorkflowInvokePayload = z.infer<typeof WorkflowInvokePayloadSchema>;
 export type HealthCheckPayload = z.infer<typeof HealthCheckPayloadSchema>;
@@ -171,6 +245,18 @@ export declare const QueuePayloadSchema: z.ZodUnion<readonly [z.ZodObject<{
         payloadDigest: z.ZodString;
         deploymentId: z.ZodOptional<z.ZodString>;
     }, z.core.$strip>>;
+    stepInput: z.ZodOptional<z.ZodObject<{
+        input: z.ZodCustom<Uint8Array<ArrayBufferLike>, Uint8Array<ArrayBufferLike>>;
+    }, z.core.$strip>>;
+    hookResumeTiming: z.ZodCatch<z.ZodOptional<z.ZodObject<{
+        resumeRequestedAtMs: z.ZodNumber;
+        queuePublishRequestedAtMs: z.ZodNumber;
+        strategy: z.ZodOptional<z.ZodString>;
+        consumerStartedAtMs: z.ZodOptional<z.ZodNumber>;
+        replayStartedAtMs: z.ZodOptional<z.ZodNumber>;
+        nextStepEncounteredAtMs: z.ZodOptional<z.ZodNumber>;
+        setupSource: z.ZodOptional<z.ZodString>;
+    }, z.core.$strip>>>;
 }, z.core.$strip>]>;
 export type QueuePayload = z.infer<typeof QueuePayloadSchema>;
 export interface QueueOptions {

package/dist/src/compiled/@workflow/world/slot-identity.d.ts

@@ -50,4 +50,19 @@ export declare function slotToEventId(slot: number): string;
  * not slot-numbered.
  */
 export declare function eventIdToSlot(eventId: string): number | null;
+/**
+ * Reads the slot out of an event id, for a caller that has no answer without
+ * one.
+ *
+ * Separate from {@link eventIdToSlot} because the two failures are different
+ * problems. A caller that can act on either scheme asks the question and takes
+ * `null` as an answer; a caller whose whole computation is positional (a
+ * precondition snapshot, a density audit) has no correct behaviour to fall back
+ * on, and silently skipping the id would make it report a position it never
+ * verified. Throwing names the id instead.
+ *
+ * @throws if the id is not slot-numbered, i.e. the World minting it does not
+ * allocate slots.
+ */
+export declare function requireEventSlot(eventId: string): number;
 //# sourceMappingURL=slot-identity.d.ts.map

package/dist/src/compiled/@workflow/world/spec-version.d.ts

@@ -37,33 +37,45 @@ export declare const SPEC_VERSION_SUPPORTS_COMPRESSION: SpecVersion;
  * and the spec version stamped on `run_created` is what carries it. A run
  * created before the backend adopted slots stays on ULIDs for its whole life
  * because its stamped version is below this one.
+ *
+ * Slots are no longer optional for a World: the runtime reads a position out
+ * of every event id it loads (`requireEventSlot`) and fails the run if it
+ * cannot. That makes this version the lowest one this runtime can serve at
+ * all. See `SPEC_VERSION_CURRENT`.
  */
 export declare const SPEC_VERSION_SUPPORTS_SLOT_IDENTITY: SpecVersion;
 /**
- * Current spec version (event-sourced architecture with native attributes
- * and compressed payloads).
+ * Current spec version: event-sourced architecture with native attributes,
+ * compressed payloads and slot-numbered event ids.
+ *
+ * This is both the version a World stamps on the runs it creates and the
+ * *lowest* one this runtime accepts from a World (see
+ * `assertWorldSupportsRuntimeProtocol`). The two coincide because slot
+ * numbering is a requirement of the World contract rather than a capability to
+ * opt into: a World declaring anything below this allocates event ids the
+ * runtime cannot read positions out of, so admitting it would only move the
+ * failure from startup to the middle of a run.
+ *
+ * A World therefore declares this constant rather than a literal, so a bump
+ * moves the declaration and the floor together. Pinning a literal would leave
+ * the adapter one version behind the next bump and get it rejected by the
+ * runtime it ships alongside.
  *
- * Deliberately NOT bumped for slot-numbered event ids. Slot numbering is a
- * property of a run's whole log rather than of an individual event, and it is
- * already self-describing: a run's scheme is readable from the shape of its
- * own first event id (see `isSlotEventId`), so a World that owns its own id
- * allocation needs no version negotiation to pin one. Bumping this constant
- * would stamp the new version on every World
- * including ones that have not adopted slots yet, which is exactly the
- * cross-version breakage the pin exists to avoid. A World that does allocate
- * slots declares the higher version itself (see `world-vercel`), and
- * `SPEC_VERSION_MAX_SUPPORTED` is what keeps this reader from rejecting the
- * runs it produces.
+ * Bumping this does not touch runs already created: their stamped version is
+ * persisted, every version test in the runtime is `>=`, and a World resolves a
+ * run's identity scheme from what is stored rather than from this constant.
  */
 export declare const SPEC_VERSION_CURRENT: SpecVersion;
 /**
  * The highest spec version this SDK can read.
  *
- * Distinct from `SPEC_VERSION_CURRENT`, which is the *default* a World stamps
- * on runs it creates. A World may declare a higher version than the default,
- * so the "was this run made by a newer SDK?" test has to be against the
- * ceiling: comparing against the default would make the SDK reject runs its
- * own adapters just created.
+ * Kept distinct from `SPEC_VERSION_CURRENT` even though the two are equal
+ * today. They answer different questions, "what do we write?" versus "what can
+ * we still read?", and they come apart in the release order a spec bump
+ * follows: a reader that can already handle the next version raises this
+ * ceiling first, and `SPEC_VERSION_CURRENT` follows only once the version is
+ * safe to stamp. Collapsing them into one constant would make that staging
+ * impossible to express.
  */
 export declare const SPEC_VERSION_MAX_SUPPORTED: SpecVersion;
 /**

package/dist/src/compiled/@workflow/world/test-support/duplicate-event-fixtures.d.ts

@@ -0,0 +1,41 @@
+import type { EventType } from '../events.js';
+/**
+ * Logs that mix events a replay reads past with events that only look like it.
+ *
+ * Two codebases answer the same question about a log and must answer it the
+ * same way. The runtime decides it while replaying: `EventsConsumer` passes
+ * over an event whose class it already consumed for that entity and which
+ * every registered callback declined. The observability UI decides it after
+ * the fact, from the log alone, with no consumers to ask. It stands in for
+ * them with the log's own record of when each entity finished, because that is
+ * the point past which the runtime has no consumer left for the entity.
+ *
+ * The two rules agree on every fixture here, and the interesting ones are the
+ * near misses: a retried step writes several `step_started` events that are
+ * all consumed, and a step that is still open absorbs a second `step_created`.
+ * Reading those as repeats would grey out attempts that ran.
+ *
+ * Each fixture is a whole run's log in log order, which is what both rules
+ * take as input. Entities are named, not correlation-id shaped, so each side
+ * can mint ids in whatever form it drives.
+ */
+export interface DuplicateEventFixtureEvent {
+    eventType: EventType;
+    /** The entity the event belongs to. Run-level events belong to none. */
+    entity?: string;
+}
+export interface DuplicateEventFixture {
+    name: string;
+    /** What makes this log worth pinning down. */
+    why: string;
+    /** One run's whole log, in log order. */
+    events: DuplicateEventFixtureEvent[];
+    /**
+     * Indices into {@link events} of the events no consumer claims: the ones the
+     * runtime steps over and the UI greys out. Every other index is an event the
+     * run acted on.
+     */
+    ignoredIndices: number[];
+}
+export declare const DUPLICATE_EVENT_FIXTURES: readonly DuplicateEventFixture[];
+//# sourceMappingURL=duplicate-event-fixtures.d.ts.map