5k issues per day distribution

[joshua-quek-sonarsource]

This fixes Issue distribution across dates

---

Note

Medium Risk
Changes how large issue migrations are represented by mutating SCM blame dates and sorting issues, which could affect issue creation dates/tracking and requires validation on diverse projects. However, batching across multiple analyses remains disabled, limiting scope to upload-time metadata shaping.

Overview
Large issue migrations no longer rely on multi-analysis batching, keeping uploads to a single scanner report to avoid SonarCloud closing issues from earlier batches.

Adds SCM-based date-bucket distribution via new backdateChangesets() that groups issues by file into ≤5k-issue buckets and rewrites per-file changeset blame dates (30-day spacing) so SonarCloud spreads issue creation dates across multiple UI buckets within the same analysis. All pipeline transferBranch entry points now invoke this before protobuf/report build, and batched transfer helpers now sort issues by component for more stable batching behavior.

Also fixes SQ 2025 issue fetching to include IN_SANDBOX and remove invalid CLOSED from the issueStatuses list, and updates the changelog to document the behavior and verification results.

^{Reviewed by Cursor Bugbot for commit a7a7116. Bugbot is set up for automated code reviews on this repo. Configure here.}

[sonar-review-alpha]

Summary

What Changed

This PR fixes the issue migration data loss for large projects (>10K issues) by replacing multi-analysis batching with SCM-based date-bucket distribution.

Problem: SonarCloud's UI caps the issues list at 10K per creation-date bucket. The old fix split large datasets into separate 5K-batch analyses, but SonarCloud's issue tracker treats each analysis as a complete snapshot—unmatched issues from prior analyses get closed. For Angular Framework (31K issues), only ~2K survived.

Solution: Keep all issues in a single analysis but spread their creation dates via SCM blame date manipulation. Issues are sorted by file and grouped into ≤5K-issue batches. Each batch's files have their changeset blame dates backdated (30 days apart), so the CE assigns different creation dates within a single upload. The UI's 10K cap is purely a display limit—all data is preserved.

Verification: Angular Framework's 31,642 issues now distribute cleanly across 7 date buckets (~4.8K per bucket), matching the SQ source data.

Also includes a fix for SQ 2025 pipeline's missing IN_SANDBOX status in the issueStatuses parameter.

What reviewers should know

Key Files to Review

• backdate-changesets.js (new) — Core algorithm. Groups issues by file into ≤5K batches, then patches each batch's SCM changeset dates. The comment block explains the strategy.
• compute-batch-date.js — Now spaces batches 30 days apart (was 1 day when used for multi-analysis).
• should-batch.js — shouldBatch() now always returns false; multi-analysis batching is disabled. Updated comment explains why.
• Pipeline entry points (6 files across sq-2025, sq-10.4, sq-10.0, sq-9.9) — All now sort issues by component and call backdateChangesets() before building the report.

Non-Obvious Decisions

• Why sort by component? Groups files contiguously so the batching algorithm can pack whole files into single batches without splitting them across date buckets.
• Why patch every line in a file? Sets all changesets to the batch date so the CE has no "newer" line to fall back on—ensures consistent creation dates per batch.
• Single analysis workaround — Exploits the CE's use of SCM blame dates (not SonarCloud's analysis date) to set issue creation dates. One analysis, multiple creation dates visible in the UI.

What to Watch

• Verify the batching logic doesn't create empty batches or leave issues unbatched in edge cases (empty components, single large file).
• Confirm the changeset modification doesn't affect any other metadata (author, revision strings are safe dummies).
• Check that all 6 pipeline transfer points are updated consistently—missing one would cause uneven date distribution.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a7a7116. Configure here.}

[cursor]

Missing backdateChangesets call in sq-2025 transfer-branch pipeline

High Severity

The sq-2025/transfer-branch/index.js entry point is the only one that was not updated to call backdateChangesets. All other pipeline entry points (sq-10.0, sq-10.4, sq-9.9, and even sq-2025's own transfer-pipeline variant) correctly call backdateChangesets(extractedData) in the non-batched path. This file still only imports shouldBatch (without backdateChangesets) and never performs SCM date-bucket distribution, so large projects migrated through the sq-2025 transfer-branch path will hit the 10K Elasticsearch visualization cap. The changelog's claim that "All 6 pipeline transfer-branch entry points" were updated is incorrect.

Additional Locations (1)

• docs/CHANGELOG.md#L35-L36

 

^{Reviewed by Cursor Bugbot for commit a7a7116. Configure here.}