Skip to content

fix(flow): scheduled agentflows never fired — invisible to the scheduler, and cron was dropped on save - #115

Merged
rubenvdlinde merged 1 commit into
developmentfrom
feat/schedule-source
Aug 2, 2026
Merged

fix(flow): scheduled agentflows never fired — invisible to the scheduler, and cron was dropped on save#115
rubenvdlinde merged 1 commit into
developmentfrom
feat/schedule-source

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Two independent causes, one symptom: a flow that ran correctly when triggered
and that nothing could trigger.

  1. OpenRegister's scheduler never asked hermiq. It enumerated one
    hard-coded store rather than the resolver registry every other trigger
    family goes through, so a hermiq agentflow with trigger: schedule was
    invisible to it. Fixed on the OpenRegister side (openregister#2260); this is
    hermiq's answer to the enumeration it introduces.
  2. agentflow had no cron property. OpenRegister drops undeclared
    properties on save, so the expression saying WHEN never persisted. A flow
    could say it ran on a schedule and could not say which one.

Measured before: zero runs with trigger='schedule' out of 52,478.
hydra-sequencer, hydra-dispatch and hydra-lock-reaper were all in that
state; the sequencer is the hydra pipeline's heartbeat.

What this adds

  • HermiqFlowResolver also implements IScheduledFlowSource, reporting
    agentflows whose trigger is schedule with their cron, enabled flag and
    owner (entity owner first, the flow's owner field as fallback — a scheduled
    run has no session, and a run with no owner cannot write, or#2158).
  • agentflow v0.1.3 gains the optional cron property; register descriptor
    v0.22.0. Optional, not required, no conditionals, so every existing AgentFlow
    stays valid.

Disabled flows are REPORTED, not filtered

The enabled flag is handed to OpenRegister rather than acted on here, so the
"a disabled flow never runs" decision is made once for the whole fleet instead
of once per app that owns flows. All ten hydra agentflows ship
enabled: false deliberately and this change does not start any of them.

Also fixes four pre-existing gate-28 findings in the same schema (AgentFlow
name/enabled/description/notes had no description).

Verified live

  • with the cron property imported, a probe agentflow saved a cron expression
    that previously vanished
  • OpenRegister's scheduler saw all five schedule-triggered agentflows on the
    instance and fired only the enabled one — the first trigger='schedule' run
    the instance has ever held — which the worker took through to completed
  • the three hydra flows (enabled false) were reported and correctly not fired
  • an A/B against the pre-change resolver: the same flow fired nothing

Gates: phpcs clean, phpstan OK, 1,421 unit tests green.

Pairs with openregister#2257 — the two halves of one defect. Merge OpenRegister first: this branch's resolver implements an interface that PR introduces.

🤖 Generated with Claude Code

…ler, and cron was dropped on save

Two independent causes, one symptom: a flow that ran correctly when triggered
and that nothing could trigger.

1. **OpenRegister's scheduler never asked hermiq.** It enumerated one
   hard-coded store rather than the resolver registry every other trigger
   family goes through, so a hermiq agentflow with `trigger: schedule` was
   invisible to it. Fixed on the OpenRegister side (openregister#2260); this is
   hermiq's answer to the enumeration it introduces.
2. **`agentflow` had no `cron` property.** OpenRegister drops undeclared
   properties on save, so the expression saying WHEN never persisted. A flow
   could say it ran on a schedule and could not say which one.

Measured before: **zero** runs with `trigger='schedule'` out of 52,478.
`hydra-sequencer`, `hydra-dispatch` and `hydra-lock-reaper` were all in that
state; the sequencer is the hydra pipeline's heartbeat.

## What this adds

- `HermiqFlowResolver` also implements `IScheduledFlowSource`, reporting
  agentflows whose trigger is `schedule` with their cron, `enabled` flag and
  owner (entity owner first, the flow's `owner` field as fallback — a scheduled
  run has no session, and a run with no owner cannot write, or#2158).
- `agentflow` v0.1.3 gains the optional `cron` property; register descriptor
  v0.22.0. Optional, not required, no conditionals, so every existing AgentFlow
  stays valid.

## Disabled flows are REPORTED, not filtered

The `enabled` flag is handed to OpenRegister rather than acted on here, so the
"a disabled flow never runs" decision is made once for the whole fleet instead
of once per app that owns flows. All ten hydra agentflows ship
`enabled: false` deliberately and this change does not start any of them.

Also fixes four pre-existing gate-28 findings in the same schema (AgentFlow
name/enabled/description/notes had no description).

## Verified live

- with the `cron` property imported, a probe agentflow saved a cron expression
  that previously vanished
- OpenRegister's scheduler saw all five schedule-triggered agentflows on the
  instance and fired only the enabled one — the first `trigger='schedule'` run
  the instance has ever held — which the worker took through to `completed`
- the three hydra flows (enabled false) were reported and correctly not fired
- an A/B against the pre-change resolver: the same flow fired nothing

Gates: phpcs clean, phpstan OK, 1,421 unit tests green.
@rubenvdlinde
rubenvdlinde requested a review from Rem-Dam as a code owner August 2, 2026 09:39
@github-actions

github-actions Bot commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/hermiq @ 7d60185

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

Coverage: 85.3% (93/109 statements)


Quality workflow — 2026-08-02 09:43 UTC

Download the full PDF report from the workflow artifacts.

@rubenvdlinde
rubenvdlinde merged commit d000fd7 into development Aug 2, 2026
33 checks passed
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