fix(oracle): make CodeQL run the dispose query + auto-pick a build target for Infer##22
Conversation
…rget The first real oracle run (DapperLib/Dapper, run 27659607294) exposed two harness gaps that made BOTH oracles silently contribute nothing — the same way the first mine exposed two extractor false positives. - CodeQL: request `queries: security-and-quality`. `cs/local-not-disposed` and the other dispose/leak queries are *quality* queries, absent from the default code-scanning (security) suite. CodeQL reported 0 leaks because the query never ran (a false zero), not because the code was clean. - Infer# build: `dotnet build target` (the repo root) hit MSB1050 on Dapper (>1 solution/project present), so the build failed and Infer# was skipped. Now pick a target: explicit `build` input wins; else a lone *.sln; else the dir (still continue-on-error -> partial report). - docs/notes/oracle.md: record both (the security-and-quality requirement and the lone-.sln autodetect). No comparator code change. oracle.yml valid YAML; oracle selftest 12/12; ruff clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rg8kSk1YT14x7A1vo5zgED
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThe Oracle workflow gains two targeted improvements: CodeQL initialization now explicitly specifies the ChangesOracle Workflow and Documentation Updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/oracle.yml:
- Around line 118-123: The `-maxdepth 2` constraint in the find command that
searches for .sln files limits discovery to only two levels deep. This causes
.sln files at greater depths to be missed, resulting in zero solutions found and
triggering an incorrect fallback to "dotnet build target". Increase the maxdepth
value or remove the maxdepth constraint entirely in the mapfile command that
uses find to locate .sln files under the target directory, allowing it to
discover solution files at any depth and ensuring the lone-.sln auto-detection
works correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: dd20efdf-25d8-4e1a-9204-f82610a2aa3c
📒 Files selected for processing (2)
.github/workflows/oracle.ymldocs/notes/oracle.md
CodeRabbit (valid, Minor): `find -maxdepth 2` would miss a repo whose only solution sits deeper, forcing the dir fallback. Their suggested unlimited `find` over-corrects, though: a repo with a clean root solution plus nested sample .slns would then read as "multiple" and fall back unnecessarily. Root-first instead: a unique root-level *.sln wins; if none at root, a unique solution anywhere (this is the deep-lone-.sln case they flagged); else fall back to the dir + a note. More robust than either fixed depth. oracle.yml valid YAML; build-step bash parses. Docs note updated to match. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rg8kSk1YT14x7A1vo5zgED
What the first real oracle run taught us
The first dispatch of
oracle (cross-tool)on DapperLib/Dapper (run 27659607294) ran the pipeline end-to-end — but as validation it was inconclusive, because both oracles silently contributed nothing. Same shape as the first corpus mine: the run exposed two harness bugs, not target bugs. This fixes both.What that run actually produced:
BenchmarkBase._connection(SqlConnection) — the known weak field-leak signalMSB1050)Fix 1 — CodeQL was running the wrong query suite
cs/local-not-disposed(and the other dispose/leak queries) are quality queries — they are not in the defaultcode-scanning(security) suite that the action runs whenqueries:is unset. So CodeQL reported 0 leaks because the query never executed, not because the code was clean.→
CodeQL initnow requestsqueries: security-and-quality.Fix 2 — Infer# build target was ambiguous on multi-project repos
dotnet build target(the repo root) failed withMSB1050: ... the folder "target" contains more than one project or solution file, soBUILD_OKwas never set and theRun Infer#step was skipped (thecontinue-on-errorpartial-report path worked as designed — but we got no Infer#).→ The build step now picks a target: explicit
buildinput wins; else a lone*.sln(auto-detected, which covers Dapper); else the dir (stillcontinue-on-error).Docs
docs/notes/oracle.mdrecords both: thesecurity-and-qualityrequirement (with the why) and the lone-.slnautodetect.Not changed
No comparator code change —
oracle_compare.pyand its--selftest(12/12) are untouched; this is purely the orchestration + docs.After merge
Re-dispatch
oracle (cross-tool)withrepo = DapperLib/Dapper(now nobuildinput needed — Dapper has a lone.sln). That should give a real Own.NET vs CodeQL(security-and-quality) vs Infer# comparison, whereagree/oracle-onlyfinally mean something.Verified
oracle.ymlvalid YAML · build-step bash parses ·ruffclean · oracle--selftest12/12.🤖 Generated with Claude Code
Generated by Claude Code
Summary by CodeRabbit
Chores
Documentation