Problem
In src/core/loop.ts, stopRequested is a module-level mutable boolean:
let stopRequested = false;
export function requestStop() {
stopRequested = true;
}
Once requestStop() is called it is never reset to false. In a single-process run that handles multiple issues sequentially (the default mode), if a stop is requested during issue #1, all subsequent issues (#2, #3, …) will immediately hit the if (stopRequested) break guard at the start of their first iteration and skip their work entirely — silently producing no output.
Suggested fix
Reset stopRequested at the beginning of each processIssue / processIssueInDir call, or change the architecture to pass a cancellation signal (e.g. AbortSignal) into the functions instead of relying on module-level state. The latter also makes the code easier to test.
export async function processIssue(
issue: GitHubIssue,
config: StormConfig,
cwd: string,
signal?: AbortSignal
): Promise<{ success: boolean; prUrl?: string }> {
// check signal.aborted instead of stopRequested
}
Problem
In
src/core/loop.ts,stopRequestedis a module-level mutable boolean:Once
requestStop()is called it is never reset tofalse. In a single-process run that handles multiple issues sequentially (the default mode), if a stop is requested during issue #1, all subsequent issues (#2, #3, …) will immediately hit theif (stopRequested) breakguard at the start of their first iteration and skip their work entirely — silently producing no output.Suggested fix
Reset
stopRequestedat the beginning of eachprocessIssue/processIssueInDircall, or change the architecture to pass a cancellation signal (e.g.AbortSignal) into the functions instead of relying on module-level state. The latter also makes the code easier to test.