Refactor (packages/opencode/src/provider/error.ts:32): Function with high complexity (count = 30): message

[afeies]

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.

1. Issue

Link to the associated GitHub issue:
#159

Full path to the refactored file:
packages/opencode/src/provider/error.ts

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)
This file normalizes provider errors.
For example, it handles

• custom error classes like timeout and stream failures
• parsing API-call failures from provider SDKs
• turning raw provider responses into a consistent, readable error message

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
I kept the change very narrow to the message-formatting section in error.ts. Specifically, I refactored the nested logic inside message(...) by splitting it into small local helpers: emptyMessage, responseBodyMessage, and gatewayMessage.
This only affects the error text generation path and leaves the rest of the file, including json(...), parseStreamError(...), and parseAPICallError(...), unchanged.

Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)
Function with high complexity (count = 30): message

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
The main issue was the nested branching inside message(...) in error.ts. That logic mixed empty-message handling, JSON-body parsing, and gateway HTML checks in one block, which made the function harder to follow and raised its complexity without adding behavior.

What changes did you make to resolve the issue?
I kept the fix minimal by extracting the repeated decision points into three small helper functions: emptyMessage, responseBodyMessage, and gatewayMessage. The main message(...) function now reads as a short sequence of checks, while each helper owns one specific branch of the old logic.

How do your changes improve maintainability? Did you consider alternatives?
This makes the error-message path easier to reason about and modify without changing the actual output behavior. I considered a full rewrite or broader cleanup, but that would have been broader than necessary; the targeted extraction keeps the refactor small and low-risk while still reducing complexity in the exact function flagged by the linter.

3. Validation

How did you validate that the change is correct?
I reran the relevant tests again to confirm the refactor did not change behavior before and after the change. I also checked the coverage report to make sure the updated code was still covered and that the refactor did not impact anything else.

bun lint

bun test

Attach a screenshot of the test coverage showing the lines were executed by the tests.

Attach a screenshot showing the tests that cover the change passing during CI

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.