Follow-up to #26.
#26 makes a run that hits a provider usage/quota limit checkpoint as paused (instead of failing), preserving its journal so /workflows resume <id> replays the completed prefix and runs only the remainder. Resuming is currently manual.
This issue tracks automatic resume once the quota refills.
What's needed
- A scheduler / restart-safe timer that fires when the limit's reset window elapses.
- A back-off + attempt cap so a run that resumes into a still-exhausted budget doesn't bounce off the wall repeatedly (it would just re-pause).
- Re-arming the timer across process restarts (a paused-for-usage-limit run should reschedule on cold start).
- Decide whether auto-resume is default-on (with an opt-out) or opt-in via
ExecOptions.
Hook already in place
The fix persists the pause reason and the provider's reset hint on the run state (pauseReason: "usage_limit", resetHint), and recoverStaleRuns() already reconciles stale runs on startup — so the scheduling layer has what it needs to build on.
Out of scope here
Parsing every provider's reset-time phrasing into an absolute timestamp — the current hint is kept verbatim; a scheduler can parse best-effort and fall back to a conservative default delay.
Follow-up to #26.
#26 makes a run that hits a provider usage/quota limit checkpoint as
paused(instead of failing), preserving its journal so/workflows resume <id>replays the completed prefix and runs only the remainder. Resuming is currently manual.This issue tracks automatic resume once the quota refills.
What's needed
ExecOptions.Hook already in place
The fix persists the pause reason and the provider's reset hint on the run state (
pauseReason: "usage_limit",resetHint), andrecoverStaleRuns()already reconciles stale runs on startup — so the scheduling layer has what it needs to build on.Out of scope here
Parsing every provider's reset-time phrasing into an absolute timestamp — the current hint is kept verbatim; a scheduler can parse best-effort and fall back to a conservative default delay.