Fix:修复新建对话时因缺少会话ID导致配置绑定失败的问题#5292
Conversation
dosubot
bot
added
the
size:M
Summary of ChangesHello @Li-shi-ling, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 此拉取请求解决了新建对话时，已选择的配置未能正确绑定到新会话的问题，导致新会话始终使用默认配置。通过在会话创建后自动执行配置绑定，并统一相关逻辑，确保用户选择的配置能在新会话中生效，提升了用户体验和系统一致性。 Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - 我发现了 1 个问题，并给出了一些高层次的反馈：
- 标记默认配置的
'default'配置 ID 在多个地方被硬编码（bindConfigToSession、useSessions中的newSession、getStoredSelectedChatConfigId）；建议把它提取成一个共享常量，这样如果默认 ID 以后发生变化就不会出现不一致。 getStoredDashboardUsername和getStoredSelectedChatConfigId假定localStorage总是可用，并且键名（'user'、'chat.selectedConfigId'）是稳定不变的；如果这些逻辑有可能在非浏览器环境中运行，或者存储结构将来发生变化，建议在访问前增加防护和/或像CHAT_SELECTED_CONFIG_STORAGE_KEY那样集中管理存储键名。
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The sentinel `'default'` config ID is hard-coded in multiple places (`bindConfigToSession`, `newSession` in `useSessions`, `getStoredSelectedChatConfigId`); consider extracting it to a shared constant to avoid divergence if the default ID ever changes.
- `getStoredDashboardUsername` and `getStoredSelectedChatConfigId` assume `localStorage` is always available and that the keys (`'user'`, `'chat.selectedConfigId'`) are stable; if there’s any chance of these running in non-browser contexts or the storage schema changing, consider guarding access and/or centralizing the storage key definitions similarly to `CHAT_SELECTED_CONFIG_STORAGE_KEY`.
## Individual Comments
### Comment 1
<location> `dashboard/src/utils/chatConfigBinding.ts:13-14` </location>
<code_context>
+ umo: string;
+}
+
+export function getStoredDashboardUsername(): string {
+ return (localStorage.getItem('user') || '').trim() || 'guest';
+}
+
</code_context>
<issue_to_address>
**issue:** Direct `localStorage` access without guarding can throw in some environments (e.g., restricted cookies / storage).
This can cause `buildWebchatUmoDetails` (and any other callers) to throw in environments like Safari private mode or with strict privacy settings. Consider wrapping `localStorage.getItem` in a try/catch and defaulting to `'guest'` on error. Applying the same pattern (or a shared `getFromLocalStorage(key, fallback)` helper) would make other call sites like `getStoredSelectedChatConfigId` safer too.
</issue_to_address>帮我变得更有用！请在每条评论上点 👍 或 👎，我会根据你的反馈改进以后的评审。
Original comment in English
Hey - I've found 1 issue, and left some high level feedback:
- The sentinel
'default'config ID is hard-coded in multiple places (bindConfigToSession,newSessioninuseSessions,getStoredSelectedChatConfigId); consider extracting it to a shared constant to avoid divergence if the default ID ever changes. getStoredDashboardUsernameandgetStoredSelectedChatConfigIdassumelocalStorageis always available and that the keys ('user','chat.selectedConfigId') are stable; if there’s any chance of these running in non-browser contexts or the storage schema changing, consider guarding access and/or centralizing the storage key definitions similarly toCHAT_SELECTED_CONFIG_STORAGE_KEY.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The sentinel `'default'` config ID is hard-coded in multiple places (`bindConfigToSession`, `newSession` in `useSessions`, `getStoredSelectedChatConfigId`); consider extracting it to a shared constant to avoid divergence if the default ID ever changes.
- `getStoredDashboardUsername` and `getStoredSelectedChatConfigId` assume `localStorage` is always available and that the keys (`'user'`, `'chat.selectedConfigId'`) are stable; if there’s any chance of these running in non-browser contexts or the storage schema changing, consider guarding access and/or centralizing the storage key definitions similarly to `CHAT_SELECTED_CONFIG_STORAGE_KEY`.
## Individual Comments
### Comment 1
<location> `dashboard/src/utils/chatConfigBinding.ts:13-14` </location>
<code_context>
+ umo: string;
+}
+
+export function getStoredDashboardUsername(): string {
+ return (localStorage.getItem('user') || '').trim() || 'guest';
+}
+
</code_context>
<issue_to_address>
**issue:** Direct `localStorage` access without guarding can throw in some environments (e.g., restricted cookies / storage).
This can cause `buildWebchatUmoDetails` (and any other callers) to throw in environments like Safari private mode or with strict privacy settings. Consider wrapping `localStorage.getItem` in a try/catch and defaulting to `'guest'` on error. Applying the same pattern (or a shared `getFromLocalStorage(key, fallback)` helper) would make other call sites like `getStoredSelectedChatConfigId` safer too.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
dosubot
bot
added
area:webui
|
Related Documentation Checked 1 published document(s) in 1 knowledge base(s). No updates required. How did I do? Any feedback? |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
本次 PR 旨在修复新建会话时未绑定配置文件的问题，通过在创建新会话后自动调用 API 绑定配置，解决了新会话始终使用默认配置的 bug。
主要改动包括：
- 在
useSessions和StandaloneChat中，于newSession成功后增加绑定配置的逻辑。 - 新增
chatConfigBinding.ts工具文件，统一了 UMO 和 LocalStorage Key 的生成规则，提高了代码的内聚性和可维护性。 - 在
ConfigSelector.vue中使用新的常量，减少了硬编码。
代码整体结构清晰，改动符合预期。我发现一处可以进一步改进的地方，以完全实现“统一 UMO 生成规则”的目标，具体请见我的评论。
| import axios from 'axios'; | ||
| import { useToast } from '@/utils/toast'; | ||
| import { useModuleI18n } from '@/i18n/composables'; | ||
| import { CHAT_SELECTED_CONFIG_STORAGE_KEY } from '@/utils/chatConfigBinding'; |
There was a problem hiding this comment.
感谢您抽出公共逻辑！这里有一个小建议，为了完全统一 UMO 的生成规则，ConfigSelector.vue 中 username 的获取方式也应该使用新的工具函数。
当前 ConfigSelector.vue 中（132行）获取用户名的逻辑是：
const username = computed(() => localStorage.getItem('user') || 'guest');这与新的工具函数 getStoredDashboardUsername（包含了 .trim() 来移除前后空格）不完全一致。如果用户名在 localStorage 中包含前后空格，这可能导致 ConfigSelector.vue 和其他部分生成的 UMO 不匹配，与本次 PR 的目标相悖。
建议进行如下修改以保持一致：
- 在此处额外导入
getStoredDashboardUsername。 - 将
username的定义（132行）更新为使用getStoredDashboardUsername。
由于相关代码行不在本次变更范围内，您可以在此文件的任意变更处进行修改，或者将其作为一次新的提交。
- 给 localStorage 访问加了 try/catch + 可用性判断：dashboard/src/utils/chatConfigBinding.ts:13 - 新增 getFromLocalStorage/setToLocalStorage（在受限存储/无痕模式下异常时回退/忽略） - getStoredDashboardUsername() / getStoredSelectedChatConfigId() 改为走安全读取：dashboard/src/utils/chatConfigBinding.ts:36 - 新增 setStoredSelectedChatConfigId()，写入失败静默忽略：dashboard/src/utils/chatConfigBinding.ts:44 - 把 ConfigSelector.vue 里直接 localStorage.getItem/setItem 全部替换为上述安全方法：dashboard/src/components/chat/ConfigSelector.vue:81 - 已重新跑过 pnpm run typecheck，通过。
dosubot
bot
added
size:L
|
修改后也进行了测试 |
|
我去！才发现删除错文件了！ |
This reverts commit 0fceee0.
2 participants
Fixes #5267
创建新会话（
GET /api/chat/new_session）后没有把“当前选择的配置文件（abconf）”绑定到该会话，导致新会话始终使用默认配置。本 PR 在新会话创建成功后，自动调用
POST /api/config/umo_abconf_route/update将所选配置绑定到该会话对应的 UMO 路由；同时对 StandaloneChat（测试配置用）补齐相同的绑定逻辑，并统一 UMO/Storage Key 的生成规则，避免多处实现不一致导致绑定无效。Modifications / 改动点
dashboard/src/composables/useSessions.tsnewSession()创建会话成功后，读取最近一次选择的配置 id（localStorage: chat.selectedConfigId），并为webchat平台自动执行配置绑定：ConfigSelector.vue一致的platformId:messageType:sessionKey格式）POST /api/config/umo_abconf_route/update写入{ umo, conf_id }dashboard/src/components/chat/StandaloneChat.vueuseSessions，因此在其newSession()中同样在会话创建后调用/api/config/umo_abconf_route/update，将props.configId绑定到新会话dashboard/src/utils/chatConfigBinding.tsdashboard/src/components/chat/ConfigSelector.vueThis is NOT a breaking change. / 这不是一个破坏性变更。
Screenshots or Test Results / 运行截图或测试结果
以下是直接在新对话切换了配置文件会进行对话的效果
Verification Steps / 验证步骤
default的配置文件。POST /api/config/umo_abconf_route/updateconf_id为所选配置 idLocal Checks / 本地检查
pnpm run typecheck（通过）ruff format .（通过）Checklist / 检查清单
没有新功能
有进行编译后的测试
requirements.txt和pyproject.toml文件相应位置。/ I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations inrequirements.txtandpyproject.toml.没有引入依赖库
没有引入恶意代码
由 Sourcery 提供的摘要
确保新创建的聊天会话自动绑定到当前选中的配置，并集中管理聊天配置绑定工具。
Bug 修复：
增强功能：
Original summary in English
Summary by Sourcery
Ensure newly created chat sessions are automatically bound to the currently selected configuration and centralize chat configuration binding utilities.
Bug Fixes:
Enhancements: