tinyhumansai/openhuman · error
[chat-factory] failed to read API key for slug '{}': {}
Error message
[chat-factory] failed to read API key for slug '{}': {} What it means
Raised when keyring/auth-store lookup of the provider bearer token fails for both the new-style key and the legacy bare-slug key for a cloud provider slug; the new-style lookup returned empty/absent and the legacy fallback errored.
Source
Thrown at src/openhuman/inference/provider/factory.rs:2580
}
let auth = AuthService::from_config(config);
// Try new-style key first.
let new_key = auth_key_for_slug(slug);
if let Ok(Some(k)) = auth.get_provider_bearer_token(&new_key, None) {
if !k.is_empty() {
log::debug!(
"[providers][chat-factory] auth lookup slug={} key_present=true (new-style)",
slug
);
return Ok(k);
}
}
// Fall back to legacy bare slug.
let key = auth
.get_provider_bearer_token(slug, None)
.map_err(|e| {
anyhow::anyhow!(
"[chat-factory] failed to read API key for slug '{}': {}",
slug,
e
)
})?
.unwrap_or_default();
if !key.is_empty() {
log::debug!(
"[providers][chat-factory] auth lookup slug={} key_present=true",
slug
);
return Ok(key);
}
// OAuth fallback for `openai` runs only after standard API-key resolution
// returns empty, so env/audit/metrics in the standard path always execute
// and the OAuth path never silently bypasses provider-agnostic logic.
if slug == "openai" {View on GitHub (pinned to 7491200858)
Solutions
- Re-store the API key for the slug (settings or keyring command) so the auth lookup succeeds
- Check the legacy error detail for a keyring backend problem (locked keychain, missing entry) and unlock/re-provision it
Defensive patterns
Strategy: fallback
When it happens
Trigger: Thrown at src/openhuman/inference/provider/factory.rs:2580 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17).
Data as JSON: /api/errors/ceaf09c20ec2e725.
Report an issue: GitHub.