Skip to content

Raise the blocking-rules poll timeout to outlast reachability triage #158

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Ibrahimrahhal wants to merge 1 commit into
base: main
Choose a base branch
from
+23 −5
Open

Raise the blocking-rules poll timeout to outlast reachability triage #158

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 23 additions & 5 deletions src/scanners/blast.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1057,8 +1057,12 @@ pub fn wait_for_scan(config: &Config, scan_id: &str, budget: WaitBudget) {
}
}

/// Match doghouse `LICENSE_DEPS_WAIT_TIMEOUT` (15 minutes).
const DEFAULT_BLOCKING_RULES_TIMEOUT: Duration = Duration::from_secs(15 * 60);
/// Must outlast the longest doghouse wait window, currently
/// `SCA_REACHABILITY_WAIT_TIMEOUT` (30 minutes), with margin for the poll
/// interval and request latency. Whichever side's clock expires first decides
/// the outcome, and this side fails closed: expiring early would hard-fail a
/// pipeline on data doghouse was about to resolve as non-blocking.
const DEFAULT_BLOCKING_RULES_TIMEOUT: Duration = Duration::from_secs(35 * 60);
const BLOCKING_RULES_POLL_INTERVAL: Duration = Duration::from_secs(2);

fn stop_blocking_rules_spinner(stop_signal: &Arc<Mutex<bool>>, spinner: thread::JoinHandle<()>) {
Expand Down Expand Up @@ -1122,7 +1126,7 @@ fn decide_blocking_rules_poll(
}

/// Poll until blocking-rules status is `complete`, or `BLOCKING_RULES_TIMEOUT_ENV`
/// (15m by default) runs out.
/// (35m by default) runs out.
/// Older backends omit status (serde defaults to complete: one-shot).
/// `block_on` is forwarded as the CI rule-slug filter (`--block-on`); `None`
/// keeps legacy `--fail` "all active rules" behavior.
Expand Down Expand Up @@ -1732,12 +1736,26 @@ mod tests {
// The docs promise these two numbers; drifting from them silently is
// the failure mode worth catching.
assert_eq!(DEFAULT_SCAN_TIMEOUT, Duration::from_secs(10 * 60 * 60));
assert_eq!(DEFAULT_BLOCKING_RULES_TIMEOUT, Duration::from_secs(15 * 60));
assert_eq!(DEFAULT_BLOCKING_RULES_TIMEOUT, Duration::from_secs(35 * 60));

@cursor cursor Bot Aug 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

README.md:43 and skills/corgea/SKILL.md:116 still promise that --fail/--block-on waits at most 15 minutes, while this line makes the shipped default 35 minutes. The mismatch is user-visible: package.json:20 includes README.md in the npm package, and operators sizing a CI job from that documented limit can now have the runner terminate the CLI before its own deadline. Please update both in-repo guides to 35 minutes in this PR so the released CLI and its bundled documentation agree.

@corgea-security corgea-security Aug 17, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this finding and think it should be addressed.

high: Update user-facing timeout documentation to 35 minutes

The default blocking-rules timeout changes from 15 to 35 minutes, but the existing review identifies README.md and skills/corgea/SKILL.md as still promising a 15-minute maximum. That contract is now false and can cause CI jobs configured around it to terminate the CLI prematurely. Update both guides with this behavioral change.

Proof or reproduction:

const DEFAULT_BLOCKING_RULES_TIMEOUT: Duration = Duration::from_secs(35 * 60);
assert_eq!(format_timeout(DEFAULT_BLOCKING_RULES_TIMEOUT), "35m");

assert_eq!(format_timeout(DEFAULT_SCAN_TIMEOUT), "10h");
assert_eq!(format_timeout(DEFAULT_BLOCKING_RULES_TIMEOUT), "15m");
assert_eq!(format_timeout(DEFAULT_BLOCKING_RULES_TIMEOUT), "35m");
assert_eq!(format_timeout(Duration::from_secs(90)), "90s");
}

#[test]
fn blocking_rules_timeout_outlasts_the_doghouse_wait_windows() {
// This side fails closed on its own deadline, so it must never expire
// while doghouse is still answering `pending`. The longest doghouse
// window is SCA_REACHABILITY_WAIT_TIMEOUT at 30 minutes.
let longest_doghouse_window = Duration::from_secs(30 * 60);
assert!(
DEFAULT_BLOCKING_RULES_TIMEOUT > longest_doghouse_window,
Comment on lines +1750 to +1752

@juangaitanv juangaitanv Aug 26, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the local 30-minute literal cannot detect Doghouse timeout changes; could we label this as a local regression guard unless a shared or versioned contract is available?

"poll deadline {DEFAULT_BLOCKING_RULES_TIMEOUT:?} must outlast the \
doghouse wait window {longest_doghouse_window:?}, or a pipeline \
hard-fails on a rule doghouse was about to resolve"
);
}

#[test]
fn budget_reports_what_is_left_and_then_nothing() {
let spent = WaitBudget::with_timeout(Duration::ZERO);
Expand Down
Loading