perf: raise default issue/hotspot sync concurrency to 50

[okorach-sonar]

Summary

Raise the default concurrency for issue and hotspot metadata sync from 20 to 50 across all 4 pipelines (sq-9.9, sq-10.0, sq-10.4, sq-2025). The previous defaults bottlenecked migrations on SonarQube Cloud API throughput rather than on round-trip latency — issueSync defaulted to 20, hotspotSync to 20 (and 5/3 in the older transfer-pipeline shortcuts).

The setting was already configurable; this PR keeps it that way and just shifts the floor up:

• Migration config: performance.issueSync.concurrency / performance.hotspotSync.concurrency (range now 1–100).
• Desktop UI: Advanced Settings → "Issue sync concurrency" / "Hotspot sync concurrency" (max raised to 100).
• CLI: --concurrency N applies to all sync stages, including hotspots — previously capped at 3 by an artifact (Math.min(options.concurrency, 3)), now lifted.

Auto-tune is unchanged — it still scales by CPU count by design.

Files changed (23)

• Schema: src/shared/config/schema-shared/helpers/performance-schema.js (defaults + max).
• Runtime resolver: src/shared/utils/system-info/helpers/resolve-performance-config.js.
• Per-pipeline syncIssues / syncHotspots fallbacks (4 pipelines, 8 files).
• Transfer-pipeline fetch-and-sync-{issues,hotspots} fallbacks (4 pipelines, 8 files).
• CLI override: src/commands/migrate/helpers/build-migrate-perf-config.js.
• Desktop UI: desktop/src/renderer/js/screens/{transfer-config,advanced-settings/renderer}.js.
• Example config: examples/migrate-config.example.json.
• Docs: docs/configuration.md.

Test plan

• Full suite: 70 pre-existing failures on main, 70 with this change. Sorted-diff confirms identical failure set — zero regressions.
• Live regression on a reference project: confirm the default-50 doesn't trip rate-limit / 503 errors on SonarQube Cloud and that the sync phase wall-clock time drops.

🤖 Generated with Claude Code

---

Note

Medium Risk
Raises default parallelism for SonarCloud issue/hotspot metadata syncing, which can increase API load and expose rate-limit/503 behavior in real migrations. Changes are mostly default/validation updates but affect runtime concurrency across multiple pipelines and the CLI/UI defaults.

Overview
Increases default SonarCloud metadata sync concurrency for both issues and hotspots to 50 across the app (including per-pipeline syncIssues/syncHotspots and transfer helpers), replacing prior lower fallbacks.

Updates config handling to match the new baseline: schema defaults and allowed max move to 1–100, desktop UI fields default/max are adjusted accordingly, and the migrate CLI --concurrency override now applies the same value to hotspot sync (removing the previous low cap). Documentation and example configs are updated to reflect the new defaults.

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

[sonar-review-alpha]

Summary

This PR raises the default concurrency for issue and hotspot metadata sync from 20 to 50 across all 4 pipelines, the schema, and the CLI. It also lifts the maximum allowed concurrency from 50 to 100, and removes a hardcoded Math.min(options.concurrency, 3) cap that was artificially limiting hotspot sync concurrency via CLI.

The change is purely a defaults/configuration adjustment with one functional improvement (the CLI cap removal). No sync logic, retry behavior, or rate-limiting logic is modified. Auto-tune scaling remains unchanged.

What reviewers should know

Verification checklist:

• Confirm the 23 file changes are all mechanical (20→50 default, or removal of the 3-cap): no logic branches, conditionals, or new complexity
• The schema max has been raised from 50 to 100 (performance-schema.js), and this is reflected in the Desktop UI max field
• Fallback defaults in all 4 pipeline syncIssues/syncHotspots functions changed from varying values (3, 5, 20) to consistent 50
• The CLI override in build-migrate-perf-config.js now passes the full --concurrency value to hotspotSync instead of capping it at 3

Rationale (already detailed in author's description):
The previous limit (20) bottlenecked on SonarQube Cloud API throughput, not latency — doubling this should reduce sync phase wall-clock time without hitting rate limits. The setting remains fully configurable (1–100 range); this just shifts the floor up.

Test results:
Full test suite shows 70 failures before and after, with sorted-diff confirming identical failure sets — zero regressions. Advise author to run live regression testing on a reference SonarQube Cloud project to confirm the default-50 doesn't trigger rate-limit errors and that sync time actually improves.

---

• 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 6f5e4d8. Configure here.}

[cursor]

Desktop defaults file not updated to match new defaults

Medium Severity

desktop/src/renderer/js/screens/advanced-settings/defaults.js still has issueSync: { concurrency: 20 } and hotspotSync: { concurrency: 20 } while the renderer, schema, and all runtime code now default to 50. This means new installations and "Reset to Defaults" will use 20 instead of 50, and AdvancedSettingsReader.readFromForm uses these stale values as parse fallbacks. The ADVANCED_DEFAULTS object was missed in this PR.

 

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