Raise the blocking-rules poll timeout to outlast reachability triage - #158
Raise the blocking-rules poll timeout to outlast reachability triage#158Ibrahimrahhal wants to merge 1 commit into
Conversation
SCA reachability blocking rules make doghouse answer `pending` for up to 30 minutes while Fusion triages a scan's direct dependencies. This side fails closed on its own deadline, so at the previous 15 minutes whichever clock expired first decided the outcome and a pipeline could hard-fail on a rule doghouse was about to resolve as non-blocking. 35 minutes leaves margin over that window for the poll interval and request latency, so doghouse always resolves first. Adds an assertion tying the two together, since the constants live in separate repos and nothing else would catch them drifting. Co-authored-by: Cursor <cursoragent@cursor.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| // 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)); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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");
There was a problem hiding this comment.
Automated review risk: 2/5.
The timeout increase is internally consistent and tested, but shipped documentation reportedly retains the old 15-minute contract and must be updated.
Critical or high-priority changes must be addressed.
Automatic approval was not submitted: automated review found critical or high-priority findings.
2 participants
Summary
SCA reachability blocking rules (Corgea/doghouse#1912) make doghouse answer
pendingfor up to 30 minutes while Fusion triages a scan's direct dependencies. This side fails closed on its own deadline, so at the previous 15 minutes whichever clock expired first decided the outcome — a pipeline could hard-fail on a rule doghouse was about to resolve as non-blocking.Raises
DEFAULT_BLOCKING_RULES_TIMEOUTto 35 minutes, leaving margin over the 30-minute window for the poll interval and request latency so doghouse always resolves first.The constants live in separate repos and nothing would otherwise catch them drifting apart, so there is an assertion pinning this deadline above doghouse's
SCA_REACHABILITY_WAIT_TIMEOUTwith a comment explaining why the ordering matters.Notes
CORGEA_BLOCKING_RULES_TIMEOUT_SECONDSstill overrides it, and the scan timeout (10 hours) is untouched.cli.mdxdocumented the old 15-minute default as of #303.Test plan
cargo test— 592 passed across all targets, rebased on currentmaintimeout_defaults_are_the_documented_onesupdated for 35m /"35m"formattingblocking_rules_timeout_outlasts_the_doghouse_wait_windowsassertionMade with Cursor