Skip to content

fix(parsers/go): give CodeQL DB-create the same timeout budget as analyze#89

Open
gadievron wants to merge 1 commit into
masterfrom
fix/parsers-go-give-codeql-db-create-the-same
Open

fix(parsers/go): give CodeQL DB-create the same timeout budget as analyze#89
gadievron wants to merge 1 commit into
masterfrom
fix/parsers-go-give-codeql-db-create-the-same

Conversation

@gadievron
Copy link
Copy Markdown
Collaborator

go/test_pipeline.py ran codeql database create with timeout=600s and codeql database analyze with
timeout=1800s. DB creation compiles the source -- the slower stage for compiled languages -- so the slower
stage had the smaller budget and times out first. On a create timeout run_codeql_analysis records the codeql
stage success=False and returns; run_full_pipeline prints "continuing with reachable units only" and proceeds,
and apply_codeql_filter (test_pipeline.py:1009, success-gated) is skipped -- so the written dataset is
reachable-only with CodeQL findings dropped. The run does report success=False / exit 1 (all_success ANDs the
failed stage, :1040-1045, :1199), so an exit-code CI gate still catches it; the harm is the silently-degraded
artifact for any consumer that reads the results rather than the exit code.

Extract both stage timeouts to named module constants and set the create budget equal to analyze (1800s), so
the create stage is no longer shortchanged.

Scope: the c/php/js/ruby test_pipeline.py orchestrators carry the same inverted timeouts and are separate
units -- not widened here.

Tests: tests/test_go_test_pipeline_codeql_timeout.py -- two checks that read the source rather than importing
the module (which does module-level sys.path manipulation and shares its name with sibling parser
test_pipeline.py): the create timeout >= analyze timeout, and that both call sites pass the named constants
(not inline literals, which could silently drift the budget back). RED -> GREEN; full suite 178 passed,
63 skipped, 0 failed.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

…lyze

go/test_pipeline.py ran `codeql database create` with timeout=600s and `codeql database analyze` with
timeout=1800s. DB creation compiles the source -- the slower stage for compiled languages -- so the slower
stage had the smaller budget and times out first. On a create timeout run_codeql_analysis records the codeql
stage success=False and returns; run_full_pipeline prints "continuing with reachable units only" and proceeds,
and apply_codeql_filter (test_pipeline.py:1009, success-gated) is skipped -- so the written dataset is
reachable-only with CodeQL findings dropped. The run does report success=False / exit 1 (all_success ANDs the
failed stage, :1040-1045, :1199), so an exit-code CI gate still catches it; the harm is the silently-degraded
artifact for any consumer that reads the results rather than the exit code.

Extract both stage timeouts to named module constants and set the create budget equal to analyze (1800s), so
the create stage is no longer shortchanged.

Scope: the c/php/js/ruby test_pipeline.py orchestrators carry the same inverted timeouts and are separate
units -- not widened here.

Tests: tests/test_go_test_pipeline_codeql_timeout.py -- two checks that read the source rather than importing
the module (which does module-level sys.path manipulation and shares its name with sibling parser
test_pipeline.py): the create timeout >= analyze timeout, and that both call sites pass the named constants
(not inline literals, which could silently drift the budget back). RED -> GREEN; full suite 178 passed,
63 skipped, 0 failed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant