fix: submit Discord Klavis auth as bot token#786
fix: submit Discord Klavis auth as bot token#786Felarof (felarof99) wants to merge 1 commit intomainfrom
Conversation
Map Discord API-key submissions to Klavis's documented bot_token auth data while preserving generic api_key auth for other integrations. Add a server feature flag for auth field overrides and keep the existing Klavis integration normalization test green. Co-Authored-By: Claude Opus 4.6 <[email protected]>
Greptile SummaryThis PR fixes Discord bot-token auth submission by mapping the
Confidence Score: 4/5Safe to merge after confirming the string-integration isAuthenticated behavior is intentional and consistent with the Klavis API contract. The core fix (Discord bot_token payload) is correct, well-tested, and cleanly implemented. One P1 concern exists: the undocumented change to treat string-typed Klavis integrations as authenticated could hide auth prompts from users if the Klavis API ever returns strings for unauthenticated integrations. packages/browseros-agent/apps/server/src/lib/clients/klavis/klavis-client.ts — specifically the normalizeIntegration change at line 149-150. Important Files Changed
Sequence DiagramsequenceDiagram
participant UI as Connect Apps UI
participant Route as submit-api-key route
participant Client as KlavisClient
participant Klavis as Klavis API
UI->>Route: POST serverName + apiKey + apiKeyUrl
Route->>Route: resolve klavisAuthFieldOverridesEnabled
Route->>Client: submitApiKey(url, key, options)
Client->>Client: getAuthFieldName(serverName, useOverrides)
Client->>Client: buildAuthData(fieldName, key)
note over Client: discord → authData.data.bot_token<br/>others → authData.api_key
Client->>Klavis: POST set-auth with instanceId + authData
Klavis-->>Client: 200 OK
Client-->>Route: resolved
Route-->>UI: success + serverName
Prompt To Fix All With AIThis is a comment left during a code review.
Path: packages/browseros-agent/apps/server/src/lib/clients/klavis/klavis-client.ts
Line: 149-150
Comment:
**Behavioral change in string integration auth status**
`normalizeIntegration` now returns `isAuthenticated: true` for string-typed entries from Klavis, whereas it previously returned `false`. If Klavis uses the plain-string format to denote integrations that are *known* but not yet authenticated (as the old default implied), this change would incorrectly show them as connected in the UI — hiding the prompt to authenticate. Can you confirm that Klavis only returns strings for integrations whose auth is already established?
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix: submit Discord Klavis auth as bot t..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if (typeof integration === 'string') { | ||
| return { name: integration, isAuthenticated: false } | ||
| return { name: integration, isAuthenticated: true } |
There was a problem hiding this comment.
normalizeIntegration now returns isAuthenticated: true for string-typed entries from Klavis, whereas it previously returned false. If Klavis uses the plain-string format to denote integrations that are known but not yet authenticated (as the old default implied), this change would incorrectly show them as connected in the UI — hiding the prompt to authenticate. Can you confirm that Klavis only returns strings for integrations whose auth is already established? Does the Klavis API return string-typed integrations only when the integration is already authenticated, or also for unauthenticated/available integrations?
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/browseros-agent/apps/server/src/lib/clients/klavis/klavis-client.ts
Line: 149-150
Comment:
**Behavioral change in string integration auth status**
`normalizeIntegration` now returns `isAuthenticated: true` for string-typed entries from Klavis, whereas it previously returned `false`. If Klavis uses the plain-string format to denote integrations that are *known* but not yet authenticated (as the old default implied), this change would incorrectly show them as connected in the UI — hiding the prompt to authenticate. Can you confirm that Klavis only returns strings for integrations whose auth is already established? Does the Klavis API return string-typed integrations only when the integration is already authenticated, or also for unauthenticated/available integrations?
How can I resolve this? If you propose a fix, please make it concise.1 participant
Summary
authData.data.bot_token, instead of genericauthData.api_key.api_keyauth data for non-Discord integrations and when the server auth-field override flag is disabled.Root Cause
BrowserOS already receives
serverNamewhen the Connect Apps UI submits an API key, but the server discarded that context.KlavisClient.submitApiKeyalways sent{ api_key: ... }, while Klavis Discord Strata docs require the Discord bot token underdata.bot_token.Feature Flag
The server-side mapping is protected by
klavisAuthFieldOverridesEnabled, defaulting to enabled. It can be disabled withBROWSEROS_KLAVIS_AUTH_FIELD_OVERRIDES=falseor configflags.klavis_auth_field_overrides: false.Test Plan
bun --env-file=.env.development test apps/server/tests/api/routes/klavis.test.ts apps/server/tests/config.test.tsbunx biome check apps/server/src/lib/clients/klavis/klavis-client.ts apps/server/src/api/routes/klavis.ts apps/server/src/config.ts apps/server/src/api/types.ts apps/server/src/api/server.ts apps/server/src/main.ts apps/server/tests/api/routes/klavis.test.ts apps/server/tests/config.test.tsbun run --filter @browseros/server typecheckReference