Instance-wide stall via automation recurrence rules that evade sub-daily frequency detection

Fix

Fixed in https://github.com/open-webui/open-webui/pull/29262 and the accompanying recurrence refactor, both released in 0.11.4. The parser takes the frequency, interval and rule count from the rule the calendar library actually built and splits the rule text on any whitespace the same way the library does, so every accepted spelling is classified and bounded alike. Every schedule evaluation also now runs outside the event loop under a two second budget, so no rule can stall the instance. Upgrading fully resolves the issue; no configuration change is required.

Root cause

Affected component: the recurrence-rule parser and validator in backend/open_webui/utils/automations.py. Reached from the automation create, update and toggle handlers in backend/open_webui/routers/automations.py, from the built-in automation tools, and from the scheduler's claim path in backend/open_webui/models/automations.py. Affected setup: 0.11.0 is affected by every spelling below; 0.11.1 to 0.11.3 are affected by the whitespace-folded spellings only.

The 0.11.0 fix bounds the work by recognising sub-second, per-minute and hourly rules and re-anchoring them near the present. It recognises them by parsing the submitted rule text a second time, by hand, and comparing the result against a fixed set of names. That second parse is stricter than the calendar library's: it matches the frequency name case-sensitively where the library is case-insensitive, it looks for rules on their own lines where the library splits on any whitespace, and it requires a rule keyword prefix the library treats as optional. A rule that any of those disagreements hides is accepted as ordinary and then walked from its stated start date, which is the unbounded behaviour the guard exists to prevent. The guard was present, but it inspected a different reading of the input than the one that was executed.

Proof of concept

Against a real instance running 0.11.0, as an account permitted to create automations. Nothing was seeded directly; each rule was submitted through the normal create endpoint.

Lower-case frequency value:

DTSTART:20000101T000000
RRULE:FREQ=secondly;INTERVAL=1

Ordinary upper-case frequency with no rule keyword prefix, which the guard misses just as completely:

DTSTART:20000101T000000
FREQ=SECONDLY;INTERVAL=1

Folding the same two lines onto one line separated by a space, or by a tab, has the same effect, as does joining two rule lines by whitespace, which additionally slips past the check that only one recurrence rule was submitted.

Submitting the first rule returned HTTP 200 after 191.59 seconds. A second client polling an unauthenticated health endpoint throughout recorded 37 timeouts across 48 attempts. Submitting the second rule returned HTTP 200 after 154.72 seconds. For comparison, the same rules spelled in the form the guard recognises are validated in under a millisecond.

Credits

@baeseungwon1010 reported the case-varied frequency value, and demonstrated that a rule differing from a benign one only in letter case reaches the unbounded path.

@Classic298 identified the remaining spellings that reach the same path with an ordinary upper-case frequency: a rule submitted without the recurrence keyword prefix, the same rule folded onto a single line by whitespace, and two recurrence rules joined by whitespace, which also defeats the single-rule check.