Repository navigation
Give schedule-triggered runs the deterministic ids the docs promise #599
Description
Problem
On the Server, schedule-triggered runs get random workflow ids, though the docs promise deterministic ones.
- The schedules guide says each triggered run gets "a deterministic workflow instance ID derived from the schedule ID and trigger timestamp", and that backfill ids are
schedule:{scheduleId}:backfill:{timestamp}. - Embedded mode does this: it builds
schedule:{id}:…ids. - The Server's schedule starter sends no
workflow_id, so every fire, backfills included, gets a generated id. Theskipoverlap policy'suse-existingduplicate policy then has no stable id to match. - No schedule surface lets the user supply an id or template.
Applications can't derive a fire's workflow id from the schedule and occurrence. Correlation and idempotent follow-up, such as signalling "the run for 09:00", behave differently between embedded mode and the Server.
Source-verified, not reproduced.
Acceptance criteria
- On the Server, scheduled and backfilled runs use the same deterministic id format as embedded mode, derived from the schedule id and occurrence time, so a repeated fire of one occurrence resolves to the same run.
- The schedules guide states the id format for both modes.
- Tests on the Server cover a normal fire, a backfill and a repeated fire of one occurrence.
Activity
rmcdaniel commentedon Oct 21, 2026
Accepted as a product defect. The next step is a focused reproduction of ordinary fire, backfill and duplicate occurrence against the published Server, then a PHP starter correction and regression coverage. Documenting random IDs is not the resolution of the promised deterministic correlation contract.
The implementation must also preserve namespace isolation from workflow#874: copying a globally colliding schedule ID pattern without the namespace correction would introduce a separate defect. Existing completed and in-flight runs retain their original identities. Native parity remains with server#325 and frozen fixtures stay unchanged. This P3 follows the current critical PHP image security release; no source fix or runtime reproduction is claimed yet.
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
Owner: Server for native schedule start identity; Workflow owns embedded occurrence/namespace contract, Docs owns the promised format. Current schedule execution generates IDs, copies schedule-level memo and writes the authoritative ScheduleTriggered occurrence marker. Parsing random workflow IDs is not a substitute for central #243's origin accessor.
Next versioned source contract derives ordinary/backfill/repeated-occurrence identity with namespace isolation and explicit max-ID/collision behavior, preserving all existing generated IDs. Coordinate deletion/reuse/buffering semantics with Workflow #876 and action-level metadata as a separate capability gap; do not retrofit deterministic IDs into frozen tuples. General reviews the format/compatibility decision before implementation or docs claim.
rmcdaniel commentedon Nov 11, 2026
Triage 2026-11-11: applies to native (schedule_execution.rs uses a random workflow_id). Blocked on a General decision: the deterministic id format. Server's proposal:
{schedule_id}-{occurrence UTC ISO-8601}, unique per namespace. Server implements once decided.rmcdaniel commentedon Nov 11, 2026
Decision (General, 2026-11-11): schedule-triggered run ids are
{schedule_id}-{YYYYMMDDTHHMMSSZ}(occurrence time, colon-free UTC basic form, URL- and filename-safe), unique per namespace. Unblocked; next: server implements. Owner: server.