Skip to content

provider: skip disabled keys when refreshing the model list - #76

Merged
yetone merged 1 commit into
yetone:mainfrom
charan-rathore:fix/disabled-keys-not-fetched
Sep 25, 2026
Merged

yetone merged 1 commit into
yetone:mainfrom
charan-rathore:fix/disabled-keys-not-fetched

Conversation

@charan-rathore

Copy link
Copy Markdown
Contributor

A key marked Off still gets called during model-list refresh, and its models show up in the picker. A disabled or expired key hits the network on every refresh. If it lists the same model as a key that is on, and says that model has fewer capabilities (for example no image input), the merged entry loses those capabilities for the active key too.

Root cause: Provider.Fetch treated len(allKeys()) > 1 as "ask every saved key". allKeys() includes KeyAccount entries with Off: true, and fetchPerKey then requests and merges those lists. KeysOn() already omits off keys.

Fix: the live fetch path uses KeysOn(). Off keys receive no requests and add nothing to the catalog. Turning a key back on includes it on the next refresh. TestOffKeyIsNotFetched covers two keys against an httptest server: zero requests and no models or capability changes while the key is off, then the key's models return after it is enabled.

go vet ./internal/provider/ ./internal/catalog/ and go test ./internal/provider/ pass.

… treated len(allKeys()) > 1 as "ask every saved key", and allKeys() includes the KeyAccount entries marked Off, so a disabled or expired key was called on every refresh and its list merged into the catalog, where a text-only answer could take image input off a model a key that is on serves; the live fetch path now uses KeysOn(), off keys get no requests and add nothing to the catalog, and turning a key back on includes it on the next refresh, covered by TestOffKeyIsNotFetched
@yetone
yetone merged commit 3212566 into yetone:main Sep 25, 2026
3 of 4 checks passed
yetone added a commit that referenced this pull request Sep 25, 2026
… which models a key sees is known only from its own list, and since #76 an off key's isn't asked, so a key turned back on (or a new one) waited for the next Refresh: a relay that hands out a key per group sent it nothing, or every model; and a Codex reasoning item whose content is null is kept for OpenAI like one without content (#75 dropped it as malformed)
@yetone

yetone commented Sep 25, 2026

Copy link
Copy Markdown
Owner

Merged (3212566) and released in v0.1.91. Thanks! Follow-up in 31aabbc: because off keys are no longer asked for models, a key that is added or turned back on now has its models fetched right away rather than waiting for the next Refresh.

@charan-rathore
charan-rathore deleted the fix/disabled-keys-not-fetched branch October 1, 2026 09:12
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.

3 participants