Agentic Analysis: Early Results

Agentic Analysis and Context Augmentation are available on your project. Here are some issues that could have been prevented. Follow the links to learn how to put them into action.

86 issue(s) found across 5 file(s):

Showing 50 of 86 issues.

_{Analyzed by SonarQube Agentic Analysis in 3.7 s}

JS-1766

Ruling Report

Code no longer flagged (1 issue)

S4782

vitest/packages/runner/src/types/tasks.ts:1365

  1363 |   /** Original file system path to the screenshot, before attachment resolution */
  1364 |   originalPath: string
> 1365 |   body?: undefined
  1366 | }
  1367 | 

Summary

This PR replaces the peach-check analysis-consistency helper to detect issue count drops scoped to SonarJS-owned languages only.

What changed:

• Switched from querying whole-project violations history (api/measures/search_history) to reconstructing unresolved-issue counts directly from api/issues/search
• Issue counts are now filtered to 5 SonarJS languages: js, ts, css, web, and yaml
• Issue reconstruction works by: fetching open issues created before each analysis point + resolving issues created before but closed after each analysis point

Why:
The old violations metric includes issues from all analyzers (non-SonarJS). When external analyzers fix issues or change their analysis scope, the signal was misinterpreted as a suspicious SonarJS drop. Filtering to SonarJS languages eliminates this noise and improves signal quality for release triage.

Impact:
Peach main-analysis triage will no longer flag false drops caused by non-SonarJS analyzer activity. The check becomes more reliable for identifying real SonarJS issues.

What reviewers should know

Start here: Begin with the main entry point fetchIssueCountsWithRetry and defaultFetchIssueCounts (lines 377–477) to understand the new reconstruction logic.

Key decisions to understand:

1. Issue reconstruction timing (lines 436–476): For each analysis date, count unresolved issues by matching creation/close timestamps. Open issues are those created before the analysis point. Resolved issues are counted if they were created before AND closed after the analysis point.

2. Language filtering (lines 36–37, 652–656): Supported languages are frozen at the top. The filter is applied directly in fetchIssuesPage by passing languages query parameter—this happens at query time, not post-processing.

3. Pagination strategy (lines 507–561): When issue search exceeds 10k results, the code splits by creation date range to paginate efficiently, then falls back to component tree traversal if needed. This handles large projects without missing results.

4. Temporal precision (lines 885–923): Timestamp formatting varies between ISO (.000Z) and Peach format (+0000). Watch for off-by-one errors in timestamp comparisons and the createdBefore exclusive boundary logic (line 444).

5. Old API deprecated (INSTRUCTIONS.md, lines 175–177): The instructions now explicitly warn against using api/measures/search_history for this check—it cannot be filtered by language and hides false drops.

Test coverage clues: Tests verify language filtering is always present in issue queries, reconstruction accuracy across open/resolved/timing boundaries, and concurrency handling for large result sets. Run tests with node --test .claude/skills/peach-check/peach-issue-history.test.js.

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

Addressed the two open review notes in 4b33afe: exported SUPPORTED_LANGUAGES from the helper so the test imports the implementation constant directly, and renamed the report metric label from violations to sonarjs_issue_count to match the reconstructed issue-count semantics. Re-ran node --test .claude/skills/peach-check/peach-issue-history.test.js after the change.

const newRules = candidate.topRulesByBaselineState.new ?? [];
const onlyTestRuleAdditions =
    newRules.length === 0 ||
    newRules.every(entry => TEST_ONLY_RULES.has(entry.rule_id));

Code Review: Refactors Peach issue history to fetch scoped, language-specific counts while improving resilience with granular retries. Please correct the Object.keys usage in diagnoseDrop, as it currently iterates over array indices rather than rule IDs.

1. 💡 Bug: Object.keys on array yields indices, not rule IDs
   Files: .claude/skills/peach-check/peach-drop-forensics.js:156

   In `diagnoseDrop`, line 156 calls `Object.keys(candidate.topRulesByBaselineState.new ?? {})`. However, `topRulesByBaselineState.new` is an **array** of `{ rule_id, count }` objects (produced by `sortCountEntries`), not a plain object. `Object.keys()` on an array returns string indices (`['0', '1', ...]`), not `rule_id` values.
   
   The variable `newRuleIds` is only used for its `.length` check, so the behavior is accidentally correct (non-empty array → non-zero length). However, the variable name and usage pattern are misleading and would break if anyone later used the values.

   Fix (Use the array directly instead of Object.keys; rename to reflect the actual type.):
   const newRules = candidate.topRulesByBaselineState.new ?? [];
   const onlyTestRuleAdditions =
       newRules.length === 0 ||
       newRules.every(entry => TEST_ONLY_RULES.has(entry.rule_id));

gitar auto-apply:on         

gitar display:verbose         

_{Was this helpful? React with 👍 / 👎 | Gitar}

const newRules = candidate.topRulesByBaselineState.new ?? [];
const onlyTestRuleAdditions =
    newRules.length === 0 ||
    newRules.every(entry => TEST_ONLY_RULES.has(entry.rule_id));

Code Review: Refactors Peach issue history to fetch scoped, language-specific counts while improving resilience with granular retries. Please correct the Object.keys usage in diagnoseDrop, as it currently iterates over array indices rather than rule IDs.

1. 💡 Bug: Object.keys on array yields indices, not rule IDs
   Files: .claude/skills/peach-check/peach-drop-forensics.js:156

   In `diagnoseDrop`, line 156 calls `Object.keys(candidate.topRulesByBaselineState.new ?? {})`. However, `topRulesByBaselineState.new` is an **array** of `{ rule_id, count }` objects (produced by `sortCountEntries`), not a plain object. `Object.keys()` on an array returns string indices (`['0', '1', ...]`), not `rule_id` values.
   
   The variable `newRuleIds` is only used for its `.length` check, so the behavior is accidentally correct (non-empty array → non-zero length). However, the variable name and usage pattern are misleading and would break if anyone later used the values.

   Fix (Use the array directly instead of Object.keys; rename to reflect the actual type.):
   const newRules = candidate.topRulesByBaselineState.new ?? [];
   const onlyTestRuleAdditions =
       newRules.length === 0 ||
       newRules.every(entry => TEST_ONLY_RULES.has(entry.rule_id));

gitar auto-apply:on         

gitar display:verbose         

_{Was this helpful? React with 👍 / 👎 | Gitar}

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube