fix(webapp): let the dashboard agent use a configurable base URL - #4738
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (32)
🧰 Additional context used📓 Path-based instructions (8)**/*.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
{packages/core,apps/webapp}/**/*.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.{ts,tsx,js,jsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.ts📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
Files:
apps/webapp/**/*.{ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Files:
apps/webapp/app/**/*.{ts,tsx}📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Files:
apps/webapp/app/**/*.ts📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Files:
**/*📄 CodeRabbit inference engine (AGENTS.md)
Files:
🔇 Additional comments (1)
WalkthroughThe change adds optional 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
f50f437 to
5075512
Compare
|
ericallam
changed the title
The agent's session start, token mint, head start, in-proxy and the client transport all assumed the agent project runs on the same Trigger instance as the webapp, deriving the agent's base URL from the webapp's own origin. When the agent project runs on a different instance, its secret key belongs to that instance, so sending it to the webapp's own API is rejected with an "Invalid API key" and the chat can't start. Add an optional DASHBOARD_AGENT_BASE_URL. The agent's base URL now resolves to it, or the SDK default when unset, and never the webapp's own origin. A concrete default rather than an unset value keeps it independent of TRIGGER_API_URL, which a webapp may point at a different host. The server call sites already funnel through one helper; the client transport reads the value from the root loader via a new useDashboardAgentBaseUrl hook.
5075512 to
2822edf
Compare
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
…ance Follow-up to #4738. That change routed the agent's session (start, token, transport, realtime) to a configurable instance, but it also moved the origin the agent's read-tools call back to. Those tools act as the user with a delegated token this webapp signs with its own SESSION_SECRET, scoped to its own user and environment, so the token can only be verified by, and the data only found on, that same instance. Split the two origins. dashboardAgentApiOrigin() stays the instance hosting the agent project (sessions, task triggers, realtime, the in forward). A new dashboardAgentUserApiOrigin() returns this webapp's own origin and is injected into the run metadata the tools use. When the agent runs on the same instance as the webapp both resolve to the same host, so nothing changes there.
…ance (#4740) ## Summary Follow-up to #4738. Splits the dashboard agent's base URL into two: the instance that hosts the agent project (used for sessions), and the instance the agent acts against as the user (used by its read-tools). #4738 only needed the first, but moved the second along with it, which breaks the tools when the agent runs on a different instance than the webapp. ## Root cause The agent's read-tools call the API as the logged-in user via a delegated user-actor token. The webapp signs that token with its own `SESSION_SECRET`, scoped to its own `userId` and `environmentId`, so it can only be verified by, and only resolves the user's data on, that same instance. #4738 routed the injected `apiOrigin` those tools use to the agent's host instance, so the token no longer verifies and the data isn't there. ## Fix `dashboardAgentApiOrigin()` stays the agent's host instance (sessions, task triggers, realtime, the `in` forward). A new `dashboardAgentUserApiOrigin()` returns the webapp's own origin (`API_ORIGIN ?? APP_ORIGIN`) and is injected into the run metadata the tools use. Same-instance deployments resolve both to the same host, so behavior is unchanged there.
2 participants
Summary
Lets the dashboard agent point at a specific Trigger instance instead of assuming it runs on the same instance as the webapp. Adds an optional
DASHBOARD_AGENT_BASE_URL; when unset it falls back to the SDK default.Root cause
The agent's session start, token mint, head start, in-proxy and the client transport all built the agent's base URL from the webapp's own origin (
API_ORIGIN ?? APP_ORIGIN). That only holds when the agent project runs on the same instance as the webapp. When it runs elsewhere,DASHBOARD_AGENT_SECRET_KEYbelongs to that other instance, so the webapp's own API rejects it with an "Invalid API key" and the chat can't start.Fix
dashboardAgentApiOrigin()now returnsDASHBOARD_AGENT_BASE_URLor the SDK default, never the webapp origin. A concrete default (rather than an unset value) keeps it independent ofTRIGGER_API_URL, which a webapp may point at a different host. Every server call site already routes through that helper; the client transport reads the value from the root loader via a newuseDashboardAgentBaseUrlhook.