Temporal Server did not bound the work performed while searching for a Schedule's next action time. An authenticated caller with namespace write permission could create or update a Schedule that combines a fine-grained cadence with an exclusion calendar that rejects every candidate time, causing the server to evaluate excluded candidates without a per-search work budget. This can consume excessive CPU in Frontend and Schedule worker components. A persisted specification can also cause its backing Schedule Workflow to repeatedly fail and retry, allowing CPU consumption to continue without additional requests until the Schedule is deleted or its backing Workflow is terminated. Repeated or parallel exploitation can deny service. The issue affects availability only; it does not expose or modify Workflow data.
In Temporal Server 1.17.x, Schedule APIs were disabled by default and the issue was reachable only when frontend.enableSchedules was enabled. Schedule APIs are enabled by default beginning in 1.18.0. In fixed releases, scheduler.specMaxIterations must remain positive. Setting it to zero or a negative value disables the hard work bound.
Until upgrading, set frontend.enableSchedules to false for namespaces that do not require Schedules. This prevents new Schedule API triggers but does not repair already-running problematic Schedules. For namespaces that must retain the feature, restrict Schedule creation and update to trusted principals and delete Schedules whose exclusions prevent next-action computation from completing. Rate limiting alone is insufficient because it does not bound the work caused by one accepted evaluation.
Upgrade to Temporal Server 1.30.7, 1.31.3, or 1.32.0, as appropriate for the deployed minor release line, and retain a positive scheduler.specMaxIterations value. The fix bounds the number of excluded candidates evaluated by each next-action search and stops the search with an error when the bound is reached. Review and replace or remove Schedule specifications that exceed the configured bound. Setting scheduler.specMaxIterations to zero or a negative value disables the hard bound.