fix: load Data's provider key when Zo injects its own token - #11
Conversation
|
This pull request addresses an issue where Data was unable to load its OpenRouter API key when deployed in an environment where Zo injects its own identity token. The fix modifies how secrets are loaded, ensuring that provider-specific keys are always read, even when the Zo token is present. This is a critical fix to ensure Data's functionality in its deployment environment.
Reviewers, please start by examining |
1 similar comment
|
This pull request addresses an issue where Data was unable to load its OpenRouter API key when deployed in an environment where Zo injects its own identity token. The fix modifies how secrets are loaded, ensuring that provider-specific keys are always read, even when the Zo token is present. This is a critical fix to ensure Data's functionality in its deployment environment.
Reviewers, please start by examining |
The service bails out of the secret loader whenever ZO_CLIENT_IDENTITY_TOKEN is already set, and a Zo-managed service always has it. So the live data-http never read DATA_OPENROUTER_API_KEY, and the first turn failed with `Provider is not configured: openrouter` — the same failure the local check missed because it ran without that token. Loading named keys loads them either way, and a value the process already carries still wins.
3501825 to
ad17afd
Compare
Why
The live
data-httpansweredProvider is not configured: openrouteron its first real question after the cutover (#10).What happened
loadZoSecrets()returns early whenZO_CLIENT_IDENTITY_TOKENis already set, and a Zo-managed service always has it injected. So the live process never read/root/.zo_secrets, never sawDATA_OPENROUTER_API_KEY, and never aliased it toOPENROUTER_API_KEY. The local check before the merge ran with a bare environment, so it loaded the file and passed.Fix
lib/zo-secrets.ts: secret parsing and selection split out of the service, withmissingSecrets(secrets, env, names?)— naming keys loads them regardless of the injected token, and a value the process already carries still wins.channels/http/index.ts: load the whole file only when Zo did not inject its token (unchanged behavior), and always load the provider keys by name.lib/zo-secrets.test.ts: covers the injected-token case that caused this.Verified
npm run typecheck,npm test— 21 passed.ZO_CLIENT_IDENTITY_TOKENset, no provider key) exports the alias from the file and answered, with citations.