preferredWorkflowId changes lose a race with the scheduler's select-then-attach window

[lsm]

maybeAttachStandaloneTasks in space-runtime.ts re-reads the task before attaching and re-checks workflowRunId and status, but not preferredWorkflowId:

const selected = await this.selectWorkflowForStandaloneTask(fresh, workflows);
if (!selected) continue;

const current = this.config.taskRepo.getTask(fresh.id);
if (!current || current.workflowRunId) continue;
if (current.status !== 'open') continue;
...
await this.startWorkflowRun(space.id, selected.id, ...)

A preference change committing between selectWorkflowForStandaloneTask and startWorkflowRun is therefore ignored: the scheduler starts workflow A while the write that chose B has already succeeded. The task runs a workflow the user did not pick, with no error anywhere.

Pre-existing — the loop dates to the #1991/#2004 era and the same window is reachable today through spaceTask.update. It is not introduced by task.setPreferredWorkflow (#4573), whose own guard covers a different window: a write landing after the task has already started.

Fixing it means including the selected preference in the attachment CAS, so a winning preference update forces the scheduler to reselect.

Found by Codex review on #4573.

Part of #4164.

[lsm]

Revalidated at 686df359d — still live, unchanged.

The loop is now attachStandaloneTasksToWorkflows at space-runtime.ts:8225; the window is at 8260-8265:

const selected = await this.selectWorkflowForStandaloneTask(fresh, workflows);
if (!selected) continue;
const current = this.config.taskRepo.getTask(fresh.id);
if (!current || current.workflowRunId) continue;
if (current.status !== 'open') continue;

Still re-reads and re-checks workflowRunId and status only. #4777 (attach fence on a trigger's row change) and #4829 touched this region without adding preferredWorkflowId to the recheck.

Cheapest correct fix is the recheck, not a new CAS: compare current.preferredWorkflowId against the value selected was chosen from and continue on mismatch, so the next tick reselects. Only reach into startWorkflowRun's attach UPDATE if you want the guarantee to hold against a writer inside that call too.

[lsm]

Re-verified against dev at 6536b5fb3 — still valid. The attach loop is now at space-runtime.ts:8283-8300. The re-read CAS checks workflowRunId and status:

const current = this.config.taskRepo.getTask(fresh.id);
if (!current || current.workflowRunId) continue;
if (current.status !== 'open') continue;

but never re-checks preferredWorkflowId, and startWorkflowRun is then called with selected.id computed before the re-read. selectWorkflowForStandaloneTask (:8329) does honour preferredWorkflowId, so the window is exactly as described.

[lsm]

Merge contract for #4574 (revalidated on current dev at 85e04c9284):

• Purpose: bind standalone-task workflow attachment to the exact preferredWorkflowId snapshot used for selection, so a winning preference update makes the scheduler reselect on a later tick.
• Production scope: space-runtime.ts and the workflow-run repository attachment CAS only.
• Test scope: focused standalone-attachment and repository regression coverage.
• Budget: at most 80 changed production lines and 120 changed test lines.
• No schema migration.