Fix/nao admin bug 1145#1209
Conversation
🚀 Preview Deployment
Preview will be automatically removed when this PR is closed. |
There was a problem hiding this comment.
1 issue found across 4 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="apps/backend/src/handlers/agent.ts">
<violation number="1" location="apps/backend/src/handlers/agent.ts:39">
P3: Follow-up admin messages with omitted `adminMode` now run against admin data but are recorded as `web` in `MessageSent`. Use resolved mode for telemetry so admin-mode usage and normal warehouse usage remain distinguishable.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
|
||
| let adminMode = opts.adminMode ?? false; | ||
| if (opts.adminMode === undefined && isProjectAdmin && opts.chatId) { | ||
| adminMode = await chatQueries.wasLastUserMessageAdmin(opts.chatId); |
There was a problem hiding this comment.
P3: Follow-up admin messages with omitted adminMode now run against admin data but are recorded as web in MessageSent. Use resolved mode for telemetry so admin-mode usage and normal warehouse usage remain distinguishable.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At apps/backend/src/handlers/agent.ts, line 39:
<comment>Follow-up admin messages with omitted `adminMode` now run against admin data but are recorded as `web` in `MessageSent`. Use resolved mode for telemetry so admin-mode usage and normal warehouse usage remain distinguishable.</comment>
<file context>
@@ -25,14 +26,19 @@ interface HandleAgentMessageResult {
+ let adminMode = opts.adminMode ?? false;
+ if (opts.adminMode === undefined && isProjectAdmin && opts.chatId) {
+ adminMode = await chatQueries.wasLastUserMessageAdmin(opts.chatId);
+ }
+
</file context>
Bl3f
left a comment
There was a problem hiding this comment.
Not sure i'd do it this way because here if you deactivate the mode on the frontend if the last message is admin then it will stay in admin, i'd stick to admin mode if first message source is admin, wdyt
|
|
||
| await agentService.assertBudget(projectId, model); | ||
|
|
||
| let adminMode = opts.adminMode ?? false; |
There was a problem hiding this comment.
unpack the adminMode if used twice
|
|
||
| let adminMode = opts.adminMode ?? false; | ||
| if (opts.adminMode === undefined && isProjectAdmin && opts.chatId) { | ||
| adminMode = await chatQueries.wasLastUserMessageAdmin(opts.chatId); |
There was a problem hiding this comment.
not sure if last user message or first user message should be considered, to me if the first message is source=admin then all the messages in the convo should be but the issue with this is that it forces it under the hood even if the user deactivate the admin mode in the frontend
There was a problem hiding this comment.
Yes actually that's what caused the issue.
I think it makes more sense to just follow the most recent message but if the user changes manually the mode, then that takes priority and hence we change the mode.
Whether that should be the first message or the last, I think most recent makes more sense
But it's true in a practical scenario the user should stick to one mode in one chat. So perhaps we could lock the mode after the first prompt in a chat
|
Really? I think I made it so that if you deactivate the mode on the frontend it takes priority over the last message mode and hence deactivates the mode. I actually tested it CleanShot.2026-07-17.at.15.51.42.mp4This is the behavior I wanted. Do you prefer something else? PS: sorry for the music, I forgot to mute |
Summary
In admin mode, follow-up questions used to quietly switch back to the normal warehouse data after the first message. Now admin mode stays on for the whole chat (#1145).
Closes #1145