Repository navigation
fix(gateway): explain rejected provider credentials - #6537
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
There was a problem hiding this comment.
Warden clearance. Complete security and confidentiality review of d2358f3212e4072f147af5460eb88bab12c6b281 found no high or medium security findings and no confidentiality findings. Any new push dismisses this approval. Analysis run
Warden: approvedNo high or medium security findings and no confidentiality findings. Reviewed |
There was a problem hiding this comment.
Warden clearance. Complete security and confidentiality review of 225de42b7c940084a7b6023f4ee081d1990ceafc found no high or medium security findings and no confidentiality findings. Any new push dismisses this approval. Analysis run
What is this about?
AI Gateway provider failures now tell members whether the organization's credential or their own credential was rejected, and who can fix it.
What problem does it solve?
A member was sent to local model settings after an organization-managed provider rejected the shared credential.
What was the situation before?
An upstream 401 or 403 appeared as a generic connection failure, even though the provider credential belonged to the organization.
How is this implemented?
provider_authentication_failed/provider_permission_deniederrors, provider ID, andx-openwork-request-id; upstream bodies are discarded and failures remain recorded.gatewayProviderAuthErrors(cloud and self-hosted, off); disabling it restores the prior recovery copy and action.What else changed?
Release note
When an AI Gateway provider rejects a credential, chat now explains who can fix it and includes a request ID for support.
Evidence
Gateway and desktop unit tests cover org/member 401/403, request IDs, and unchanged personal-key copy. No real-app screenshot: local MySQL could not start because Docker reported an image-store I/O error.
Design: P3, C6, T2