Skip to content

Refactor (packages/opencode/src/provider/error.ts): Function with many returns - #65

Open
lilyqin7 wants to merge 4 commits into
CMU-313:mainfrom
lilyqin7:main
Open

Refactor (packages/opencode/src/provider/error.ts): Function with many returns#65
lilyqin7 wants to merge 4 commits into
CMU-313:mainfrom
lilyqin7:main

Conversation

@lilyqin7

@lilyqin7 lilyqin7 commented Sep 5, 2026

Copy link
Copy Markdown

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue:
#28

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 turns provider failures into consistent error infromation that OpenCode can display.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)
parseStreamError
This function reads error messages and classifies the messages appropriately.

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 many returns (count = 7): parseStreamError

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
Having multiple return statements in parseStreamError means that any future shared processing, such as logging or normalizing results, may need to be added to several exit points. Using a result variable and a final return provides one place for that processing. However, multiple returns are not inherently harder to maintain: direct returns make each switch case self-contained and prevent fallthrough. The refactor introduces a need for correct variable initialization and break statements.

What changes did you make to resolve the issue?
I used a variable that stores the final result instead of having multiple return statements for each result possibility.

How do your changes improve maintainability? Did you consider alternatives?
My changes give parseStreamError a single return point, making it easier to add shared processing, such as logging or normalization, in the future.

3. Validation

How did you validate that the change is correct?
bun lint and bun test ran without additional errors. Additionally, I ran qlty smells --no-snippets packages/opencode/src/provider/error.ts to ensure the many returns error went away and no new errors were introduced. For bun test, I identified that the tests that covered parseStreamError are in test/session/message-v2.test.ts. I did not add to the tests in this suite since they were already covering all of parseStreamError.

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

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

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

@lilyqin7
lilyqin7 marked this pull request as ready for review September 5, 2026 22:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant