refactor(core): hoist redirect following out of getInputStream

[w0rxbend]

Clears three maintainability findings — scala:S3776 ×2 on RuntimeHttp.scala and scala:S107 on StatefulApplyRunner.scala. These are the only open Sonar findings in production Scala; the other 79 are test code.

Tests first, because the branches being refactored were uncovered

follow's redirect-failure exits were 1-of-4 covered — only "unsafe redirect target" was asserted. Refactoring uncovered branches is how they change behaviour quietly, so this PR adds the three missing cases before touching production code:

• redirect budget exhausted
• missing or blank Location
• malformed Location

Each asserts the error message and that the response body was closed. All three pass before the refactor and after.

The two S3776 findings were the same code counted twice

Sonar reports complexity 22 at getInputStream:38 and 17 at follow:46. follow was a nested @tailrec def, so its branching aggregated into the enclosing method on top of a nesting surcharge — one method scored twice, once through its child.

Hoisting follow to object level clears both. Extracting helpers while leaving it nested would have left the outer method around 14–15 and flickering across the threshold on the next edit.

redirectTarget and provenanceFor come out as siblings.

Three things that are load-bearing, not incidental

• The redirect target stays a match, not a for-comprehension. Moving the recursive call inside a flatMap lambda takes it out of tail position and @tailrec fails compilation.
• redirectTarget leaves the response open on every path, success and failure alike. The body belongs to the caller, which releases it through failClosing; closing it here would double-close.
• provenanceFor's two arms draw on different sources on purpose. A chain this loop followed itself is recorded in redirects; a response that never redirected here may still have been redirected by the transport, and only the response carries that history. They are not collapsible.

getInputStream's public signature is unchanged, so its three callers are untouched.

StatefulApplyRunner

runWithState drops its fileSystem parameter, which duplicated installer.fileSystem, taking it from 8 parameters to 7. The single caller in ResolvingBinaryInstallerService is updated.

This is redundant state, not a latent bug. The object is private[core], the method is private, and the caller passed installer.fileSystem literally — the divergence was not constructible. Removing it for tidiness, not for safety.

Verification

scalafmt/checkFormatAll, __.compile under -Werror -Wunused:all -Wvalue-discard -Wnonunit-statement, and __.test all pass — 514 tests, 0 failures. The new HttpClientTest cases were also run against the pre-refactor code to confirm they pass on both sides of the change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AaPvsFt1xYoXErXaZ4Kk8A

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 22ef340c-f0a0-43be-8d8c-b495a9f9f051

---

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.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud