Source workflow reported a bug.
Linear: https://linear.app/roy/issue/ROY-21/how-could-we-continuous-to-process-new-tasksjobs
PR: #7
Details:
In src/workflow.ts, resolveGlobalPollingSettings(projects) returns projects[0].polling and runWorkflow then uses shouldStopPolling(globalPolling, ...) plus sleep(globalPolling.intervalMs). Under --all-projects, polling behavior for every project is governed by the first configured project's interval/maxCycles/exitWhenIdle, ignoring other projects' polling config. Regression risk: mixed project configs can terminate the loop prematurely (e.g., first project maxCycles=1) or keep looping unexpectedly (first project exitWhenIdle=false), and use the wrong poll interval for non-first projects. Add tests covering multi-project polling with divergent project polling configs and adjust stop/sleep logic to aggregate per-project settings safely.
Source workflow reported a bug.
Linear: https://linear.app/roy/issue/ROY-21/how-could-we-continuous-to-process-new-tasksjobs
PR: #7
Details:
In src/workflow.ts, resolveGlobalPollingSettings(projects) returns projects[0].polling and runWorkflow then uses shouldStopPolling(globalPolling, ...) plus sleep(globalPolling.intervalMs). Under --all-projects, polling behavior for every project is governed by the first configured project's interval/maxCycles/exitWhenIdle, ignoring other projects' polling config. Regression risk: mixed project configs can terminate the loop prematurely (e.g., first project maxCycles=1) or keep looping unexpectedly (first project exitWhenIdle=false), and use the wrong poll interval for non-first projects. Add tests covering multi-project polling with divergent project polling configs and adjust stop/sleep logic to aggregate per-project settings safely.