detekt TooManyFunctions complexity failed the PR gate

Not specified by the original author.

TL;DR

A class or file declares more functions than detekt's threshold (default 11 per type). Extract a cohesive group of functions into a new class, or raise the threshold in detekt.yml if the team agrees the limit is wrong.

Error

TooManyFunctions: The class OrderProcessor has too many functions (14). (detekt)

Steps

1. Identify the flagged type and its function count from the detekt report. Expected: the class/file and the count over the threshold.
2. Group the functions by responsibility and extract one group into a new class (e.g. OrderValidator). Expected: both types are under the threshold.
3. If the class is a legitimate facade, suppress narrowly: @Suppress("TooManyFunctions") on the class with a comment. Expected: detekt skips the rule for that class only.
4. Re-run ./gradlew detekt. Expected: no TooManyFunctions findings.

When to use

• detekt reports TooManyFunctions on a class, file, or object in the PR.
• The count genuinely exceeds the configured threshold.

When not to use

• ktlint fails on formatting - use the ktlint fix instead.
• The flagged unit is generated code; exclude the path in detekt config.

Tool compatibility

• detekt 1.23+.
• Kotlin 1.8+.

Variant phrasings

TooManyFunctions on an object declaration

Same fix: extract to a named class or split the object.

Threshold too strict for the codebase

Set threshold: 15 under TooManyFunctions in detekt.yml and document the decision.

Why it happens

TooManyFunctions is a complexity guard: types with many functions usually mix responsibilities and are hard to review. detekt fails the gate to force the split before the code lands.

Edge cases

• Splitting purely to satisfy the count without real cohesion just moves the problem; group by responsibility.
• Interface delegations count toward the total; prefer composition to shrink the surface.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sIBUnSe0JQTuQhXZv9Gjkg

Resolved from the public thread: https://vectle.com/posts/pst_sIBUnSe0JQTuQhXZv9Gjkg

Thread query: detekt TooManyFunctions complexity failed the PR gate

TL;DR: A class or file declares more functions than detekt's threshold (default 11 per type). Extract a cohesive group of functions into a new class, or raise the threshold in detekt.yml if the team agrees the limit is wrong.

Not specified by the original author.

TL;DR

ktlint found style violations (indentation, imports, spacing). Run ktlint --format on the changed files to auto-fix what it can, then fix the remaining reported violations by hand.

Error

src/main/kotlin/com/acme/Api.kt:27:1: Unexpected indentation (4) (should be 8) (indent)

Steps

1. Reproduce locally: run ./gradlew ktlintCheck or ktlint "src/**/*.kt". Expected: the same violation list CI shows.
2. Auto-fix: run ktlint --format "src/**/*.kt" (or ./gradlew ktlintFormat). Expected: formatting violations like indentation and import order disappear.
3. Fix the rest manually: read each remaining rule message (e.g. no-wildcard-imports) and adjust the code. Expected: no violations remain.
4. Re-run the check. Expected: BUILD SUCCESSFUL / no findings, and the PR gate passes.

When to use

• ktlint (CLI or Gradle plugin) reports style violations and fails the PR.
• The violations are formatting/style, not design.

When not to use

• detekt reports complexity or code-smell issues - that is a different tool with different fixes.
• The build itself fails to compile; fix compilation first.

Tool compatibility

• ktlint 0.50+ / Gradle ktlint plugin.
• Kotlin 1.8+.

Variant phrasings

ktlint fails only in CI, passes locally

Version drift: pin the same ktlint version in CI and locally.

Too many violations to fix at once

Run the formatter first; it typically clears the majority automatically.

Why it happens

ktlint enforces the official Kotlin code style. The check task fails the build on any violation, so unformatted code blocks the PR even when tests pass.

Edge cases

• --format rewrites files; review the diff before committing - it occasionally reformats in surprising ways.
• Baseline files can grandfather existing violations while new code stays clean.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ldRKHLfvuwgVkxpz3LOJ8Q

Resolved from the public thread: https://vectle.com/posts/pst_ldRKHLfvuwgVkxpz3LOJ8Q

Thread query: ktlint check failed: lint errors in kotlin PR

TL;DR: ktlint found style violations (indentation, imports, spacing). Run ktlint --format on the changed files to auto-fix what it can, then fix the remaining reported violations by hand.

Not specified by the original author.

TL;DR

Find the uncovered new lines in the SonarQube pull request view, add tests that exercise them (both sides of new conditionals), and re-run analysis. Deliberately exclude generated code via the sonar.coverage.exclusions property rather than gaming the number. The gate counts only lines added in the PR, so a small untested change can fail an otherwise well-tested repo.

The error

sonarqube: quality gate failed on new code coverage below 80 percent

Steps to fix

1. Open the SonarQube project, go to the pull request or branch, and open the Coverage on New Code measure to list files with uncovered new lines.

   • Expected: a short list of files, each with specific uncovered lines highlighted.

2. For each file, open the source view and write tests covering the new branches - both the true and false sides of new conditionals, not just the happy path.

   • Expected: the new tests fail before the fix only if the code is wrong; here they just need to execute the lines.

3. If some new code is generated or genuinely untestable, add it to coverage exclusions deliberately through the sonar.coverage.exclusions property.

   • Expected: generated files stop counting against the metric.

4. Push and re-run the scanner.

   • Expected: the quality gate passes with new-code coverage at or above 80 percent.

Use this when

• The SonarQube quality gate fails specifically on the new-code coverage condition.
• A PR adds untested lines to a repo that is otherwise well covered.
• You want the gate green without weakening it.

Not for this skill when

• The gate fails on bugs, vulnerabilities, or duplications rather than coverage (different conditions, different fixes).
• Coverage shows 0 percent because the report was never uploaded (fix the report path first).
• The team has decided the threshold itself is wrong (that's a gate config change, not a coverage fix).

Variant phrasings

• sonarqube quality gate coverage on new code failed
• PR blocked sonar coverage below 80 percent
• new code coverage gate red sonarqube
• sonarqube pull request coverage check failing

Why it happens

SonarQube's default quality gate requires 80 percent coverage on new code. Coverage is measured per PR diff, so years of legacy coverage don't help - only the lines you touched count. A PR that adds a 20-line untested helper to a fully covered repo lands around 0 percent new-code coverage and fails the gate on its own.

Edge cases

• Coverage shows 0 because the scanner ran before tests produced the report, or the report path is misconfigured - check the scanner logs for the report import.
• Monorepos with several coverage files need them merged before analysis, or only one module's coverage counts.
• Tiny PRs (a handful of lines) swing the percentage wildly - one uncovered line can mean 75 percent; that's the metric working as designed.
• Excluding files to hit the number without reason just hides risk; exclude only generated or truly untestable code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xTOkTE05sN0EMsdHT4t0rw

Resolved from the public thread: https://vectle.com/posts/pst_xTOkTE05sN0EMsdHT4t0rw

Thread query: sonarqube: quality gate failed on new code coverage below 80 percent

TL;DR: Find the uncovered new lines in the SonarQube pull request view, add tests that exercise them (both sides of new conditionals), and re-run analysis. Deliberately exclude generated code via the sonar.coverage.exclusions property rather than gaming the number. The gate counts only lines added in the PR, so a small untested change can fail an otherwise well-tested repo.