Skip to content

fix(flow): scheduled runs were ownerless — 4th instance of the attribution defect - #2173

Merged
rubenvdlinde merged 1 commit into
developmentfrom
fix/scheduled-flow-attribution
Jul 28, 2026
Merged

fix(flow): scheduled runs were ownerless — 4th instance of the attribution defect#2173
rubenvdlinde merged 1 commit into
developmentfrom
fix/scheduled-flow-attribution

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Fourth instance of the or#2158 defect class, after FlowMcpToolProvider::runFlow(), FlowRunService::execute() and FlowRunController::test().

The defect

FlowScheduleService::fire() queued with no user, so every natively-scheduled flow ran ownerless: context['triggeredBy'] was null and every attribution-requiring node refused. ObjectWriteNode returns "This flow run has no owner (triggeredBy); an object write must be attributable." A scheduled flow could therefore never write anything.

Why this one is urgent rather than theoretical

FlowRunWorker and FlowScheduleWorker were registered for the first time in #2172 — before that, 24 of 31 declared jobs were never in oc_jobs, so scheduled flows silently never ran at all. Now they do run. Without this fix they would run and refuse, producing a steady stream of failed runs on every instance that picks up that change.

The fix

A scheduled run has no session, so the owner comes from the flow object itself — the person who created and enabled it. That matches the standing decision that a dispatch is owned by whoever made and activated the flow.

Verification

New test asserts queue() receives the owner; FlowScheduleServiceTest 7/7 green.

Found while writing the apphost-schedule-flow-action spec — the spec work looked at the adjacent scheduler and found the same hole.

🤖 Generated with Claude Code

Fourth instance of the or#2158 defect class, after FlowMcpToolProvider::runFlow(),
FlowRunService::execute() and FlowRunController::test().

FlowScheduleService::fire() queued with no user, so every natively-scheduled flow
ran ownerless: context['triggeredBy'] was null and every attribution-requiring
node refused. ObjectWriteNode returns 'This flow run has no owner (triggeredBy);
an object write must be attributable.' A scheduled flow could therefore never
write anything.

A scheduled run has no session, so the owner comes from the flow object itself —
the person who created and enabled it, matching the decision that a dispatch is
owned by whoever made and activated the flow.

This became urgent rather than theoretical: FlowRunWorker and FlowScheduleWorker
were registered for the first time in #2172, so scheduled flows now actually
execute. Without this fix they would execute and refuse, producing a steady
stream of failed runs.

Test asserts queue() receives the owner; 7/7 green in FlowScheduleServiceTest.
@rubenvdlinde
rubenvdlinde merged commit b375a0b into development Jul 28, 2026
15 of 18 checks passed
@rubenvdlinde
rubenvdlinde deleted the fix/scheduled-flow-attribution branch July 28, 2026 05:45
@github-actions

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/openregister @ 24d6f4c

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
composer ✅ 174/174
npm ✅ 555/555
PHPUnit ⏭️
Newman ⏭️
Playwright ⏭️

Quality workflow — 2026-07-28 05:48 UTC

Download the full PDF report from the workflow artifacts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant