Skip to content

refactor: reduce cognitive complexity of bandwidthChecker.emitWindowMetric - #181

Merged
joshiste merged 1 commit into
mainfrom
fix/bandwidth-metric-complexity
Aug 6, 2026
Merged

refactor: reduce cognitive complexity of bandwidthChecker.emitWindowMetric#181
joshiste merged 1 commit into
mainfrom
fix/bandwidth-metric-complexity

Conversation

@joshiste

@joshiste joshiste commented Aug 6, 2026

Copy link
Copy Markdown
Member

Summary

SonarCloud flagged emitWindowMetric's cognitive complexity at 19 against the 15 allowed (surfaced on #180, which merged before this fix could land). Extracts the threshold evaluation (isWithinThreshold) and label-building (windowMetricLabels) into their own functions - no behavior change, same tests pass unmodified.

Test plan

  • go test ./exthttpcheck/... (including -race) passes
  • go build, go vet, gofmt -l clean

…etric

SonarCloud flagged emitWindowMetric at a cognitive complexity of 19
against a limit of 15 (from #180, merged before this fix landed).
Extracts the threshold evaluation and label-building into their own
functions - no behavior change.
@claude

claude Bot commented Aug 6, 2026

Copy link
Copy Markdown

Claude finished @joshiste's task in 1m 14s —— View job


Claude's Review

Tasks:

  • Check for previously unresolved Claude review threads to resolve (none found)
  • Gather context (diff, changed file)
  • Review new changes for bugs, security, performance, concurrency issues
  • Post final review

Summary

This is a clean, mechanical refactor that extracts two pure helper functions — isWithinThreshold and windowMetricLabels — out of emitWindowMetric to bring its cognitive complexity under SonarCloud's threshold. I compared the extracted logic line-by-line against the pre-refactor version (origin/main) and confirmed it's behavior-preserving:

  • isWithinThreshold: the min/max bandwidth checks and the errorCount > 0 && bytesDownloaded == 0 stall check are unchanged, same order, same log statements.
  • windowMetricLabels: label construction, the http_status/expected_http_status block, and the error block are unchanged, just parameterized instead of closing over c/locals.
  • Counter increments (counterWindowSuccess/counterWindowFailed) still happen based on the same withinThreshold value, in the same relative position with no dependency on the label-building that follows.

No concurrency issues — both extracted functions operate purely on values already copied out from under windowMu in emitWindowMetric, so no new locking concerns are introduced.

No bugs, security, or performance issues found in the diff. Nothing outstanding to flag.

Note: I was unable to run go build/go vet/gofmt/go test in this sandbox (Bash commands beyond git/gh required approval that wasn't available). The PR description states these were run locally and pass; the manual diff review above didn't surface anything that would contradict that.

@joshiste
joshiste enabled auto-merge (squash) August 6, 2026 11:14
@sonarqubecloud

sonarqubecloud Bot commented Aug 6, 2026

Copy link
Copy Markdown

@joshiste
joshiste merged commit c2aed82 into main Aug 6, 2026
13 checks passed
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 6, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant