fix(flow): scheduled runs were ownerless — 4th instance of the attribution defect - #2173
Merged
Merged
Conversation
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.
Contributor
Quality Report — ConductionNL/openregister @
|
| 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fourth instance of the or#2158 defect class, after
FlowMcpToolProvider::runFlow(),FlowRunService::execute()andFlowRunController::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.ObjectWriteNodereturns "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
FlowRunWorkerandFlowScheduleWorkerwere registered for the first time in #2172 — before that, 24 of 31 declared jobs were never inoc_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;FlowScheduleServiceTest7/7 green.Found while writing the
apphost-schedule-flow-actionspec — the spec work looked at the adjacent scheduler and found the same hole.🤖 Generated with Claude Code