Skip to content

fix(opencode): expose config parse errors over http#29238

Open
YOMXXX wants to merge 1 commit into
anomalyco:devfrom
YOMXXX:fix/http-config-error-details
Open

fix(opencode): expose config parse errors over http#29238
YOMXXX wants to merge 1 commit into
anomalyco:devfrom
YOMXXX:fix/http-config-error-details

Conversation

@YOMXXX
Copy link
Copy Markdown

@YOMXXX YOMXXX commented May 25, 2026

Issue for this PR

Closes #29200

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Config JSON/JSONC parse and schema validation errors can be thrown as defects during startup request fanout. The generic HTTP error middleware was converting those defects into an opaque 500 response, so clients only saw Unexpected server error.

This keeps the generic 500 behavior for unknown and unrelated named defects, but returns structured ConfigJsonError and ConfigInvalidError responses with HTTP 400 so the CLI/TUI can render the actual config path and validation issue.

How did you verify your code works?

  • bun test test/server/httpapi-error-middleware.test.ts from packages/opencode
  • bun typecheck from packages/opencode
  • bun turbo typecheck from repo root
  • .husky/pre-push from repo root

Screenshots / recordings

Not applicable.

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

@github-actions
Copy link
Copy Markdown
Contributor

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found

PR #29208 - fix(config): catch parse errors gracefully during startup
#29208

Why it might be related: This PR also addresses config parse errors during startup, which is directly related to PR #29238's focus on exposing config parse errors (both JSON/JSONC parsing and schema validation) over HTTP with proper error responses.

@YOMXXX
Copy link
Copy Markdown
Author

YOMXXX commented May 25, 2026

Thanks for the duplicate check. This is related to #29208, but it takes a different approach.

#29208 changes config loading to swallow parse/schema failures and fall back to defaults. This PR keeps config parse/schema failures intact and only maps ConfigJsonError / ConfigInvalidError defects at the HTTP boundary to structured 400 responses, so startup request aggregation can show the actual config path and validation issue instead of a generic 500.

The regression coverage is in test/server/httpapi-error-middleware.test.ts, and unrelated named defects still return the safe generic 500 body.

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.

Invalid JSON/C causes "Unexpected server error" on startup

1 participant