Repository navigation
fix(core): explain OpenCode Go key recovery - #56670
sayedrisat wants to merge 2 commits into
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
There was a problem hiding this comment.
Thanks for picking this up. As written, though, the new hint won't reach users. The expired-key error from OpenCode Go is an HTTP 401 rejection before any streaming starts. It surfaces as an AIError with reason Authentication, and toSessionError in packages/core/src/session/to-session-error.ts maps it to provider.auth. It never becomes a provider-error stream event. As far as I can tell, no protocol in packages/ai emits that event type at all. I ran Go's exact message (from #56586) through classifyProviderFailure and toSessionError, and it came out as provider.auth with the original upstream text unchanged. Typecheck in packages/core passes.
Public API unchanged.
To make this work, the rewrite belongs where authentication errors are turned into session errors: toSessionError, which already rewrites ChatGPT token-sharing messages by code (tokenSharingMessages). Better still, the Console/Go server could return accurate recovery text, since the misleading "Signing in again will not renew this key" comes from upstream. Matching on the message text is fragile either way. If the server sends an error code, match on that. A small test that feeds a 401 with this body through toSessionError would show the fix actually takes effect.
The docs section in go.mdx looks fine as it is.
| case "provider-error": | ||
| providerFailed = true | ||
| yield* failAssistant({ type: "provider.unknown", message: event.message }) | ||
| yield* failAssistant({ |
There was a problem hiding this comment.
This branch never runs for an expired key. The Go gateway rejects the request with HTTP 401 before streaming, so the failure arrives as an AIError (Authentication) and goes through toSessionError as provider.auth. It never reaches a provider-error stream event, and I couldn't find any protocol in packages/ai that emits one. I checked by feeding the exact message from #56586 through classifyProviderFailure and toSessionError, and the original text comes back unchanged. The rewrite would need to go into toSessionError/providerError in to-session-error.ts (next to tokenSharingMessages), or into the server's error response.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Issue for this PR
Closes #56586
Type of change
What does this PR do?
The expired Go key is rejected as a 401 before streaming, so the recovery hint now lives in
toSessionError. It replaces the upstream message when the 401 body contains its current expiry wording, and the test covers that path. The Go Console docs include the recovery steps too. The response has no error code to match, so the rewrite is scoped to 401 plus the distinctive upstream wording.How did you verify your code works?
The
session-error.test.tssuite passed 10 reruns.bun run typecheckpassed inpackages/core, and the repository pre-pushbun run checkpassed.Screenshots / recordings
Not applicable.
Checklist