Repository navigation
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Requesting changes. I ran the #54686 reproduction from source, and this fixes the reported case: with the base, the anthropic baseURL-only overlay makes claude-haiku-5-5 the default and fails with ConnectionRefused. With this PR, both configs fall back to openai/gpt-6.1-sol. The three test files you ran pass (41 tests), and bun run typecheck in packages/core passes.
The problem is that the fix brings back #42790. #42791 deliberately made every configured provider enabled so that availability would not depend on settings.apiKey. This change ties it to inline apiKey/authToken/accessToken again. I checked with a quick test on a catalog provider (xai) with no credential:
baseURLplus a custom auth header (headers: { "x-api-key": … }): available on the base, unavailable with this PR.- only a local
baseURL(e.g. a keyless proxy): available on the base, unavailable with this PR.
Those users would have to add apiKey: "" again, which is the workaround #42790 was about. Please fix #54686 without breaking those setups. For example, keep config-enabled providers usable when selected explicitly, but leave providers without a connection or a configured credential out of the implicit default model choice. That is the other direction suggested in the issue. Whatever you choose, please add a test for the header-authenticated gateway case.
Public API: the config schema is unchanged, but the meaning of an existing config changes: a providers.<catalog-id> entry with only settings, headers or body and no inline key no longer makes that provider available. That is not backwards compatible for keyless or header-authenticated gateway setups.
Related: #42790
| integrationID: provider.integrationID, | ||
| }) | ||
| provider.activation = "enabled" | ||
| // Request overlays alone must not bypass a catalog provider's credential check. |
There was a problem hiding this comment.
This brings back #42790. A catalog provider configured with a baseURL plus a custom auth header (or a keyless local endpoint) stays auto and drops out of available(), unless the user adds an inline key. I tested xai with settings.baseURL + headers: { "x-api-key": "…" }: it was available on the base and is unavailable here. It also ties activation to apiKey/authToken/accessToken again, which #42791 removed on purpose. A fix that keeps these providers usable when selected explicitly, but leaves providers without a connection or configured credential out of the implicit default, would fix #54686 without this regression.
There was a problem hiding this comment.
Fixed in 863ea44. Configured providers remain enabled, preserving explicit header-authenticated and keyless gateway selection from #42791. Credential/connection eligibility now applies only to implicit default selection, including the resolver's package fallback; an explicit configured default remains honored.
Added header-auth and keyless gateway regressions: both fail against the previous PR implementation and pass with the fix. All 89 targeted tests, core typecheck, and root lint/typecheck passed.
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Closes #54686
Type of change
What does this PR do?
Configured providers remain available for explicit selection, including header-authenticated gateways and keyless local endpoints. Implicit default selection skips providers without an active connection or configured credential, so a baseURL-only overlay cannot replace the existing default. Explicit configured defaults are still honored.
How did you verify your code works?
89 tests passed across config/provider, config/model, model, and model-resolver. The header-auth and keyless gateway regressions both failed on the previous PR implementation and pass with this fix. Core typecheck and root lint/typecheck passed; the pre-push hook ran with Astro telemetry disabled and forwarded to child tasks.
Screenshots / recordings
N/A (provider configuration logic).
Checklist
Added by the opencode bot (AI-generated).
Related: #42790
Public API: no schema change, but a
providers.<catalog-id>entry with only settings/headers/body no longer makes that provider available (not backwards compatible for keyless or header-authenticated gateway configs)