feat: implement issue #418 — SonarCloud: reduce cognitive complexity (S3776, CRITICAL) (×4)

[don-petry]

Closes #418

Implemented by dev-lead agent. Please review.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Warning

Review limit reached

@don-petry, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: c6c3ad9f-7e17-492f-b452-735415ebae4d

📥 Commits

Reviewing files that changed from the base of the PR and between 0fb5caf and cad0472.

⛔ Files ignored due to path filters (2)

• _bmad/bmm/workflows/4-implementation/bmad-retrospective/workflow.md is excluded by !_bmad/**
• _bmad/bmm/workflows/4-implementation/bmad-sprint-status/workflow.md is excluded by !_bmad/**

📒 Files selected for processing (7)

• .github/skills/bmad-retrospective/workflow.md
• .github/skills/bmad-sprint-status/workflow.md
• deploy/index.html
• sonar-project.properties
• src/calendar-to-sheets/src/index.js
• src/gmail-to-drive-by-labels/src/index.js
• src/gmail-to-drive-by-labels/tests/code.test.js

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dev-lead/issue-418-20260715-0317

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[don-petry]

Dev-Lead — review-changes (no-changes)

No changes were needed for this PR.

[github-actions]

CI Failure: SonarCloud Code Analysis

Step: Quality Gate check
Root cause: Test failure

The SonarCloud Quality Gate failed because Coverage on New Code is 0.0%, well below the required 80% threshold. This PR (deploy/index.html) refactors handleDeploy into several new functions — resolveProjectId, deploySingleScript, buildDeploySuccessHtml, and buildDeployErrorHtml — none of which are exercised by any test suite, so all newly added lines report zero coverage.

Suggested fix: Add unit tests covering resolveProjectId, deploySingleScript, buildDeploySuccessHtml, and buildDeployErrorHtml (e.g. mocking apiFetch to test the stored-project-reuse path, new-project-creation path, and both success/error HTML builders) so new-code coverage meets the 80% gate.

View run logs

[Copilot]

Pull request overview

Refactors four SonarCloud S3776 (cognitive complexity) hotspots by extracting helper functions and flattening control flow while preserving existing behavior in the Gmail-to-Drive, Calendar-to-Sheets, and deployment UI code paths.

Changes:

• gmail-to-drive-by-labels: Extracted helpers for blob byte access, heading/separator insertion, attachment handling, and label-group processing.
• calendar-to-sheets: Split sync logic into focused helpers for upsert/insert and window-bounded deletion decisions.
• deploy/index.html: Extracted deployment subroutines (project resolution, single-script deploy, success/error HTML builders) to simplify the main handler.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/gmail-to-drive-by-labels/src/index.js	Breaks up message/attachment processing and label-group orchestration into smaller helpers to reduce cognitive complexity.
src/calendar-to-sheets/src/index.js	Extracts upsert/insert/delete-window helpers to simplify syncCalendarToSheet.
deploy/index.html	Extracts project resolution/deploy/status-rendering helpers to simplify deployment flow and reduce complexity.

[don-petry]

Dev-Lead — fix-bot-comment (applied)

Changes committed and pushed.

[github-actions]

CI Failure: SonarCloud Code Analysis

Step: Quality Gate condition new_coverage
Root cause: Config error

The SonarCloud Quality Gate failed because new_coverage is 0.0%, below the required 80% threshold (all other conditions passed). This PR adds sonar.javascript.lcov.reportPaths=coverage/lcov.info to sonar-project.properties, but .github/workflows/sonarcloud.yml never runs npm test -- --coverage or produces that file — it only checks out the repo and runs the SonarCloud scan action. A separate coverage.yml workflow does generate coverage/lcov.info via npm test -- --coverage, but it runs as an independent job/workflow with no shared filesystem or artifact hand-off to the SonarCloud job, so the scanner never sees a real coverage report and treats all new lines (544 additions across deploy/index.html, the two src/**/index.js refactors) as uncovered.

Suggested fix: In .github/workflows/sonarcloud.yml, add steps to set up Node 20, run npm ci and npm test -- --coverage before the SonarCloud Scan step (or upload the lcov report as a build artifact in coverage.yml and download it in sonarcloud.yml), so coverage/lcov.info exists on disk when the scanner runs.

View run logs

[don-petry]

Dev-Lead — review-changes (applied)

Changes committed and pushed.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[don-petry]

Dev-Lead — review-changes (no-changes)

No changes were needed for this PR.

[github-actions]

CI Failure: SonarCloud Code Analysis

Step: Quality Gate — New Code Coverage check
Root cause: Test failure

The SonarCloud Quality Gate failed because coverage on new code is 0.0%, below the required 80% threshold. This PR adds several new functions in deploy/index.html (resolveProjectId, deploySingleScript, buildDeploySuccessHtml, buildDeployErrorHtml) with no accompanying unit tests, so none of that new logic is exercised by the test suite, driving the new-code coverage metric to zero.

Suggested fix: Add unit tests covering resolveProjectId, deploySingleScript, buildDeploySuccessHtml, and buildDeployErrorHtml in deploy/index.html (e.g. mocking apiFetch to test the stored-vs-created project branches and the success/error HTML builders) so new-code coverage rises above 80%.

View run logs

[don-petry]

@donpetry-bot dev-lead follow-up — add test coverage to unblock the SonarCloud gate.

This PR fails the SonarCloud quality gate on new_coverage (0.0% < 80%): the refactor changed lines that aren't exercised by the existing Jest suite, so SonarCloud counts them as uncovered new code. The pr-review agent (correctly) won't approve past a failing quality gate.

Requested change: add characterization/unit tests that execute the refactored functions (the 4 S3776 targets in this PR) so the changed lines are covered and new_coverage clears 80%. Behavior is unchanged, so these are pure characterization tests around existing behavior. Keep them in the existing Jest layout; npm test + npm run check must stay green.

Once coverage lands and SonarCloud goes green, the PR-review agent can approve.

[donpetry-bot]

@don-petry I'm on it — starting a fresh review now. Results will appear in a few minutes.

[don-petry]

Closing as part of the 50-PR cap drain. The dev-lead fix-loop repairs #1340 (self-cancellation), #1290 (comment-inertness) and #806 (thread-resolution) have all landed, so this deadlocked PR can be regenerated cleanly through the repaired loop. The driving issue stays open and its dev-lead label is re-fired — no work is lost.