feat: use webmcp-cli to intelligently transform the project#203
Merged
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR migrates MCP page-tool registration to navigator.modelContext-based registration, adds WebMCP polyfill and types, switches token persistence to localStorage, simplifies router/login guards, and updates per-component tool wiring and skill documentation. ChangesWebMCP Tool Integration and Auth Migration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (5)
template/tinyvue/src/router/guard/menu.ts (1)
141-161: ⚡ Quick winDuplicated root-redirect logic across both branches.
The "redirect
rootto resolved default leaf" block at Lines 144-150 is repeated at Lines 154-160. Extracting it into a small helper reduces drift risk.♻️ Proposed extraction
+function redirectRootToDefault(router: Router, to: any, next: any) { + if (to.name === 'root') { + const defaultRoute = resolveDefaultRouteName(router) + if (defaultRoute) { + next({ name: defaultRoute, replace: true }) + return true + } + } + return false +} + const menuStore = useMenuStore() if (!menuStore.menuList.length) { const data = await menuStore.getMenuList() addMenuRoutes(router, data) - if (to.name === 'root') { - const defaultRoute = resolveDefaultRouteName(router) - if (defaultRoute) { - next({ name: defaultRoute, replace: true }) - return - } - } + if (redirectRootToDefault(router, to, next)) { + return + } next({ ...to, replace: true }) return } - if (to.name === 'root') { - const defaultRoute = resolveDefaultRouteName(router) - if (defaultRoute) { - next({ name: defaultRoute, replace: true }) - return - } - } + if (redirectRootToDefault(router, to, next)) { + return + } next()🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/router/guard/menu.ts` around lines 141 - 161, The two identical "root -> default route" blocks should be extracted into a small helper to avoid duplication: create a function (e.g., handleRootRedirect or redirectRootToDefault) that accepts router, to, next, calls resolveDefaultRouteName(router), and if to.name === 'root' and a defaultRoute exists calls next({ name: defaultRoute, replace: true }) returning true/false as needed; then replace both inline blocks in the menu guard with calls to that helper (invoke it after addMenuRoutes(...) and again in the else path), using menuStore.getMenuList, addMenuRoutes, resolveDefaultRouteName, router, to, and next as before.template/tinyvue/src/utils/auth.ts (1)
4-4: Security posture: tokens now persist inlocalStorage.Switching from
sessionStoragetolocalStoragemakes the auth and refresh tokens readable by any script on the origin and persists them indefinitely across browser sessions, widening the XSS exfiltration window. This is the intended trade-off for cross-tab login continuity, but consider whetherhttpOnly/Securecookies (or a short-lived in-memory access token + refresh cookie) are viable given your threat model, and ensure tokens are cleared on logout (handled inclearToken) and on token expiry.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/utils/auth.ts` at line 4, The code sets const storage = localStorage which persists tokens across sessions and increases XSS risk; change this to use sessionStorage (const storage = sessionStorage) or migrate token storage to httpOnly Secure cookies (or keep access token in memory and refresh token in a cookie) and update token-handling functions (e.g., getToken, setToken, clearToken) to read/write the new storage mechanism; also ensure clearToken explicitly removes tokens from both storage and any cookies if you support both for a safe logout path.template/tinyvue/src/App.vue (1)
27-54: ⚡ Quick winUnregister these app-level tools on unmount.
Both tools are registered under fixed names, but there is no matching cleanup. If
App.vueremounts during HMR or an embedded-app lifecycle, duplicate registration can break subsequent mounts.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/App.vue` around lines 27 - 54, The two tools registered in the onMounted block (via navigator.modelContext.registerTool) using the names 'navigate_url' and 'system-overview' are not cleaned up; add an onBeforeUnmount handler that calls the modelContext unregister/deregister method for those same tool names (e.g., navigator.modelContext.unregisterTool('navigate_url') and navigator.modelContext.unregisterTool('system-overview') or the correct API variant) to remove both registrations when App.vue unmounts so remount/HMR won't create duplicates.template/tinyvue/src/views/userManager/info/components/info-tab.vue (1)
107-116: 💤 Low valueRedundant
getAllRole()calls during setup.
jobFilterperforms a top-levelawait getAllRole()(Line 110) andfetchRole()(Line 354) issues a second identical request on the same mount. Consider fetching once and reusing the result to avoid the duplicate network round-trip.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/views/userManager/info/components/info-tab.vue` around lines 107 - 116, The code currently calls getAllRole() twice—once in the top-level await when building jobFilter and again in fetchRole()—causing duplicate network requests; fix by calling getAllRole() only once (e.g., in setup/mounted or inside fetchRole()) and store the result in a shared reactive/local variable (e.g., rolesRef) and then set jobFilter.value.values from that shared result; update jobFilter initialization to use the shared roles variable (without an extra await) and remove the redundant getAllRole() call in either the top-level jobFilter construction or in fetchRole(), ensuring jobFilter, fetchRole, and the shared rolesRef are the single source of truth.template/tinyvue/src/views/menu/info/components/info-tab.vue (1)
272-285: ⚖️ Poor tradeoffFixed
sleep(1000)couples the tool to UI timing.Relying on two hard-coded 1s waits for the modal/form to mount and to settle is fragile—slower environments can run the handler before refs are ready, and faster ones waste time. Prefer awaiting
nextTick/a readiness signal (e.g. resolving onceaddMenu.valueis defined) instead of fixed delays. Same pattern recurs in the other migrated tool handlers.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/views/menu/info/components/info-tab.vue` around lines 272 - 285, The handler uses fixed sleep(1000) delays around handleAddMenu and addMenu.value access which couples logic to UI timing; change handleAddMenu logic to await a readiness signal instead: call handleAddMenu(), then await Vue's nextTick or a Promise that resolves when addMenu.value is non-null (e.g. poll or event), then compute parentId via getIdByLabel(i18nMenuData.value, parentMenu) and call addMenu.value.setMenuInfo(...); remove both sleep(1000) calls and apply the same readiness-based replacement wherever sleep is used in the other migrated handlers.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.gitignore:
- Line 14: Remove the "pnpm-lock.yaml" entry from .gitignore and add/commit the
pnpm-lock.yaml file to the repo so the WebMCP dependency graph and transitive
changes are reproducible and reviewable; edit the .gitignore to delete the
pnpm-lock.yaml line and run git add pnpm-lock.yaml && git commit to include the
lockfile in the PR.
In `@template/tinyvue/src/App.vue`:
- Around line 39-42: The navigate_url tool's execute handler calls
router.push(url) but doesn't await or handle navigation failures, then always
returns success after sleep(1000); update navigate_url.execute to await the
promise returned by router.push(url), wrap it in try/catch (or use .then/.catch)
to detect navigation failures/aborts, and only return the success payload ({
content: [...] 收到: ${url} }) when navigation resolves; on error return a failure
payload indicating the navigation error (include the error message) so callers
won't see a false positive. Ensure you update the function that references
router.push and sleep (navigate_url.execute) so it awaits router.push(url) and
handles thrown/rejected errors appropriately.
In `@template/tinyvue/src/skills/tiny-pro-operator/SKILL.md`:
- Line 3: The runtime guidance in SKILL.md currently hard-codes the dev origin
"http://localhost:3031" in the TinyPro link and teaches a deployment-specific
base URL; update the "我的系统是一个 [TinyPro](http://localhost:3031/vue-pro/) ..."
line to use a route-relative path (e.g. "/vue-pro/...") or an origin-relative
reference (e.g. use the current origin) instead so the `navigate_url` guidance
and the "system-overview" wording do not embed a localhost dev URL.
- Around line 31-34: The fenced code blocks in SKILL.md that show the example
user requirement and tool call (the blocks containing lines like
`用户需求：添加国际化词条：key 为 test::page::title，内容为「测试页面」，语言为中文` and
`工具调用：add-i18n-entry({ key: "test::page::title", content: "测试页面", lang: 2 })`)
need language annotations to satisfy MD040; update each triple-backtick fence
(including the other occurrences of the same example blocks) to include a
language specifier such as ```text so the fences become annotated (e.g., ```text
... ```), and apply the same change to the other reported blocks in the file.
In `@template/tinyvue/src/views/locale/components/add-locale.vue`:
- Around line 80-98: addLang (and similarly addLocale) currently calls
langForm.value.validate().then(...) without handling validation rejections and
assumes error objects have response.data.message; fix by attaching a .catch(...)
to the validate() call (or convert validate block to async/await with try/catch)
so validation failures are handled and do not create unhandled rejections, and
inside the createLang/.catch handler use safe access (optional chaining) to read
the error message (e.g., reason.response?.data?.message ?? reason.message ??
'Unknown error') before passing to Notify; ensure the existing finally logic
that resets lang.name and calls setLangPopoverClose() still runs.
- Around line 154-163: The execute handler is returning success immediately
because addLocale() is fire-and-forget; change addLocale (the method that
validates and calls createLocalItem) to return its Promise (propagate validation
failures and createLocalItem rejections) and then await addLocale() inside
execute before returning the success payload so errors are propagated back to
the caller; ensure execute catches/re-throws or returns error results when
addLocale rejects so the MCP tool is not told "已添加..." on failure.
In `@template/tinyvue/src/views/menu/info/components/info-tab.vue`:
- Around line 263-288: The execute handler currently resolves before the create
completes and can throw if addMenu.value is missing; update execute to await the
full add flow and handle errors: ensure onClickAdd returns the promise that
represents the validate→createMenu chain (so onClickAdd() is awaitable), then in
execute call await onClickAdd() instead of fire-and-forget, and wrap the body in
try/catch to catch errors (including missing addMenu.value) and return a failure
result when exceptions occur; keep the existing setMenuInfo call
(addMenu.value.setMenuInfo) and use getIdByLabel as before but guard
addMenu.value existence before calling setMenuInfo.
- Around line 250-262: The inputSchema in info-tab.vue lacks a real default for
order so execute's call to addMenu.value.setMenuInfo({ order }) can pass
undefined and break validation; update the tool's execute logic to normalize
order (use order ?? 0) before calling addMenu.value.setMenuInfo, and for
parentMenu guard the lookup by only calling getIdByLabel(i18nMenuData.value,
parentMenu) when parentMenu is a non-empty string (otherwise set parentId: null
or omit it) to avoid unnecessary lookups; make these changes in the execute
function that prepares the payload for addMenu.value.setMenuInfo and reference
getIdByLabel and i18nMenuData.value accordingly.
In `@template/tinyvue/src/views/role/info/components/info-tab.vue`:
- Around line 247-253: The role lookup calls getAllRoleDetail() with no args so
it only fetches the first page and misses roles; update the execute handler to
call getAllRoleDetail with the role as the name filter (or fetch the correct
page/iterate pages) before searching, e.g. invoke getAllRoleDetail({ name: role
}) (or include appropriate page/limit) and then use
data.roleInfo.items.find(...) and pass the found rowData into
roleTableRef.value.openMenuModal(rowData.menus, rowData.id, rowData); ensure the
unique symbols mentioned (execute, getAllRoleDetail, data.roleInfo.items,
roleTableRef.value.openMenuModal) are updated accordingly.
---
Nitpick comments:
In `@template/tinyvue/src/App.vue`:
- Around line 27-54: The two tools registered in the onMounted block (via
navigator.modelContext.registerTool) using the names 'navigate_url' and
'system-overview' are not cleaned up; add an onBeforeUnmount handler that calls
the modelContext unregister/deregister method for those same tool names (e.g.,
navigator.modelContext.unregisterTool('navigate_url') and
navigator.modelContext.unregisterTool('system-overview') or the correct API
variant) to remove both registrations when App.vue unmounts so remount/HMR won't
create duplicates.
In `@template/tinyvue/src/router/guard/menu.ts`:
- Around line 141-161: The two identical "root -> default route" blocks should
be extracted into a small helper to avoid duplication: create a function (e.g.,
handleRootRedirect or redirectRootToDefault) that accepts router, to, next,
calls resolveDefaultRouteName(router), and if to.name === 'root' and a
defaultRoute exists calls next({ name: defaultRoute, replace: true }) returning
true/false as needed; then replace both inline blocks in the menu guard with
calls to that helper (invoke it after addMenuRoutes(...) and again in the else
path), using menuStore.getMenuList, addMenuRoutes, resolveDefaultRouteName,
router, to, and next as before.
In `@template/tinyvue/src/utils/auth.ts`:
- Line 4: The code sets const storage = localStorage which persists tokens
across sessions and increases XSS risk; change this to use sessionStorage (const
storage = sessionStorage) or migrate token storage to httpOnly Secure cookies
(or keep access token in memory and refresh token in a cookie) and update
token-handling functions (e.g., getToken, setToken, clearToken) to read/write
the new storage mechanism; also ensure clearToken explicitly removes tokens from
both storage and any cookies if you support both for a safe logout path.
In `@template/tinyvue/src/views/menu/info/components/info-tab.vue`:
- Around line 272-285: The handler uses fixed sleep(1000) delays around
handleAddMenu and addMenu.value access which couples logic to UI timing; change
handleAddMenu logic to await a readiness signal instead: call handleAddMenu(),
then await Vue's nextTick or a Promise that resolves when addMenu.value is
non-null (e.g. poll or event), then compute parentId via
getIdByLabel(i18nMenuData.value, parentMenu) and call
addMenu.value.setMenuInfo(...); remove both sleep(1000) calls and apply the same
readiness-based replacement wherever sleep is used in the other migrated
handlers.
In `@template/tinyvue/src/views/userManager/info/components/info-tab.vue`:
- Around line 107-116: The code currently calls getAllRole() twice—once in the
top-level await when building jobFilter and again in fetchRole()—causing
duplicate network requests; fix by calling getAllRole() only once (e.g., in
setup/mounted or inside fetchRole()) and store the result in a shared
reactive/local variable (e.g., rolesRef) and then set jobFilter.value.values
from that shared result; update jobFilter initialization to use the shared roles
variable (without an extra await) and remove the redundant getAllRole() call in
either the top-level jobFilter construction or in fetchRole(), ensuring
jobFilter, fetchRole, and the shared rolesRef are the single source of truth.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ff648411-db7a-4a64-962f-026996ab366b
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (17)
.gitignoretemplate/tinyvue/package.jsontemplate/tinyvue/src/App.vuetemplate/tinyvue/src/main.tstemplate/tinyvue/src/router/constant.tstemplate/tinyvue/src/router/guard/menu.tstemplate/tinyvue/src/router/guard/permission.tstemplate/tinyvue/src/skills/index.tstemplate/tinyvue/src/skills/tiny-pro-operator/SKILL.mdtemplate/tinyvue/src/utils/auth.tstemplate/tinyvue/src/views/locale/components/add-locale.vuetemplate/tinyvue/src/views/login/index.vuetemplate/tinyvue/src/views/menu/info/components/info-tab.vuetemplate/tinyvue/src/views/permission/info/components/info-tab.vuetemplate/tinyvue/src/views/role/info/components/info-tab.vuetemplate/tinyvue/src/views/userManager/info/components/info-tab.vuetemplate/tinyvue/tsconfig.json
💤 Files with no reviewable changes (1)
- template/tinyvue/src/views/login/index.vue
shenjunjian
reviewed
Jun 4, 2026
shenjunjian
reviewed
Jun 4, 2026
shenjunjian
reviewed
Jun 4, 2026
shenjunjian
reviewed
Jun 4, 2026
shenjunjian
reviewed
Jun 4, 2026
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
template/tinyvue/src/skills/tiny-pro-operator/SKILL.md (1)
149-152: ⚡ Quick winClarify date-time format for temporal parameters.
The
probationDate,protocolStart, andprotocolEndparameters accept date-time strings, but the table doesn't specify the expected format. Based on the schema ininfo-tab.vue(context snippet 2), these use ISO 8601 date-time format. Consider adding format examples (e.g.,"2026-01-15T10:30:00Z") to help agents construct valid payloads.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/skills/tiny-pro-operator/SKILL.md` around lines 149 - 152, Update the SKILL.md table to clarify the expected date-time format for temporal fields: explicitly state that `probationDate` (string[]), `protocolStart` (string), and `protocolEnd` (string) must use ISO 8601 date-time format and include an example such as "2026-01-15T10:30:00Z" (or date-only "2026-01-15" if allowed) so agents know how to construct valid payloads; reference the schema in info-tab.vue for consistency and ensure the table cells for these fields include the format note and example.template/tinyvue/src/views/login/index.vue (1)
15-17: 💤 Low valueConsider using a route name instead of hardcoded path.
The hardcoded path
/vue-pro/board/workreduces maintainability. If the route path changes, this redirect will break silently.♻️ Suggested refactor using route name
if (getToken()) { - router.push('/vue-pro/board/work') + router.push({ name: 'work-board' }) // or appropriate route name }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/views/login/index.vue` around lines 15 - 17, Replace the hardcoded path in the automatic redirect with a named-route push: locate the getToken() check and change the router.push('/vue-pro/board/work') call to router.push({ name: '<ROUTE_NAME>' }) using the route name defined in your router config (or import the route name constant if you maintain a central route names file); ensure the name you use matches the route's name in your router (e.g., the route for the board/work view).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@template/tinyvue/src/router/guard/permission.ts`:
- Line 33: The progress bar is started with NProgress.start() but never finished
for authenticated users; update the authenticated navigation path in the
permission guard to call NProgress.done() immediately after next() (referencing
the next() call in this file) or alternatively add a router.afterEach(() =>
NProgress.done()) hook to centrally finish the progress bar; ensure
NProgress.done() is invoked in the same control flow where next() is used (or
globally in afterEach) so the progress bar always completes.
In `@template/tinyvue/src/skills/tiny-pro-operator/SKILL.md`:
- Line 166: The section heading "### 6. `navigate_url` — 导航到指定URL" is a
duplicate number with the earlier "add-user" section; update the heading number
to "### 7. `navigate_url` — 导航到指定URL" so section numbering is sequential
(referencing the `add-user` and `navigate_url` headings in SKILL.md).
---
Nitpick comments:
In `@template/tinyvue/src/skills/tiny-pro-operator/SKILL.md`:
- Around line 149-152: Update the SKILL.md table to clarify the expected
date-time format for temporal fields: explicitly state that `probationDate`
(string[]), `protocolStart` (string), and `protocolEnd` (string) must use ISO
8601 date-time format and include an example such as "2026-01-15T10:30:00Z" (or
date-only "2026-01-15" if allowed) so agents know how to construct valid
payloads; reference the schema in info-tab.vue for consistency and ensure the
table cells for these fields include the format note and example.
In `@template/tinyvue/src/views/login/index.vue`:
- Around line 15-17: Replace the hardcoded path in the automatic redirect with a
named-route push: locate the getToken() check and change the
router.push('/vue-pro/board/work') call to router.push({ name: '<ROUTE_NAME>' })
using the route name defined in your router config (or import the route name
constant if you maintain a central route names file); ensure the name you use
matches the route's name in your router (e.g., the route for the board/work
view).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4fabd650-b8c5-422c-9aa7-82e5eab7b021
📒 Files selected for processing (9)
template/tinyvue/src/router/guard/permission.tstemplate/tinyvue/src/skills/tiny-pro-operator/SKILL.mdtemplate/tinyvue/src/utils/auth.tstemplate/tinyvue/src/views/locale/components/add-locale.vuetemplate/tinyvue/src/views/login/index.vuetemplate/tinyvue/src/views/menu/info/components/info-tab.vuetemplate/tinyvue/src/views/permission/info/components/info-tab.vuetemplate/tinyvue/src/views/role/info/components/info-tab.vuetemplate/tinyvue/src/views/userManager/info/components/info-tab.vue
💤 Files with no reviewable changes (1)
- template/tinyvue/src/utils/auth.ts
🚧 Files skipped from review as they are similar to previous changes (5)
- template/tinyvue/src/views/menu/info/components/info-tab.vue
- template/tinyvue/src/views/role/info/components/info-tab.vue
- template/tinyvue/src/views/locale/components/add-locale.vue
- template/tinyvue/src/views/userManager/info/components/info-tab.vue
- template/tinyvue/src/views/permission/info/components/info-tab.vue
There was a problem hiding this comment.
♻️ Duplicate comments (2)
template/tinyvue/src/views/menu/info/components/info-tab.vue (2)
271-285:⚠️ Potential issue | 🟠 Major | ⚡ Quick winReplace the fixed sleeps with an explicit modal-ready check.
Lines 272 and 284 add a hardcoded 2s delay, but they still do not guarantee
addMenu.valueexists because<AddMenu>is behindv-if="addModal". On a slow mount this can still fail at Line 274; on a fast mount every tool call pays unnecessary latency. Wait for the ref with a Vue tick/ready signal and guardaddMenu.valuebefore callingsetMenuInfo().In Vue 3, when a child component rendered behind `v-if` becomes visible, when is its template ref guaranteed to be populated, and is `await nextTick()` the recommended way to wait for it instead of arbitrary timeouts?🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/views/menu/info/components/info-tab.vue` around lines 271 - 285, The current code uses fixed sleep() calls around handleAddMenu() and onClickAdd(), which is brittle because <AddMenu> is behind v-if="addModal" and addMenu.value may not be populated; replace the sleeps with an explicit wait for the child ref to be ready (use Vue's nextTick or a Promise-based ready signal) and guard addMenu.value before calling addMenu.value.setMenuInfo(...); specifically update the sequence around handleAddMenu(), getIdByLabel(i18nMenuData.value, parentMenu), addMenu.value.setMenuInfo(...), and await onClickAdd() to await nextTick() (or a resolved ready promise emitted by the child) after opening the modal and before calling setMenuInfo, removing the hardcoded sleep calls.
65-93:⚠️ Potential issue | 🟠 Major | ⚡ Quick winBubble add failures back to
execute.
onClickAdd()still returns normally on validation errors and API errors, so Line 285 can complete and Line 286 still reports success even when no menu was created. Please return an explicit success/failure result here, or rethrow, so the MCP response matches the actual outcome.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@template/tinyvue/src/views/menu/info/components/info-tab.vue` around lines 65 - 93, onClickAdd currently swallows validation and API errors causing callers (execute) to think the add succeeded; modify onClickAdd to propagate failure by either rethrowing the caught error or returning an explicit boolean result: return true on full success (after createMenu, TinyModal success, updateUserMenu and fetchMenu) and on validation failure or API error either throw the error (so the promise rejects) or return false (so execute can check the result); ensure setAddLoading(false) still runs in the finally block and keep references to addMenu.value.valid(), addMenu.value.getMenuInfo(), createMenu(...), updateUserMenu(), and fetchMenu() so callers can detect real outcome.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@template/tinyvue/src/views/menu/info/components/info-tab.vue`:
- Around line 271-285: The current code uses fixed sleep() calls around
handleAddMenu() and onClickAdd(), which is brittle because <AddMenu> is behind
v-if="addModal" and addMenu.value may not be populated; replace the sleeps with
an explicit wait for the child ref to be ready (use Vue's nextTick or a
Promise-based ready signal) and guard addMenu.value before calling
addMenu.value.setMenuInfo(...); specifically update the sequence around
handleAddMenu(), getIdByLabel(i18nMenuData.value, parentMenu),
addMenu.value.setMenuInfo(...), and await onClickAdd() to await nextTick() (or a
resolved ready promise emitted by the child) after opening the modal and before
calling setMenuInfo, removing the hardcoded sleep calls.
- Around line 65-93: onClickAdd currently swallows validation and API errors
causing callers (execute) to think the add succeeded; modify onClickAdd to
propagate failure by either rethrowing the caught error or returning an explicit
boolean result: return true on full success (after createMenu, TinyModal
success, updateUserMenu and fetchMenu) and on validation failure or API error
either throw the error (so the promise rejects) or return false (so execute can
check the result); ensure setAddLoading(false) still runs in the finally block
and keep references to addMenu.value.valid(), addMenu.value.getMenuInfo(),
createMenu(...), updateUserMenu(), and fetchMenu() so callers can detect real
outcome.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 47aaada2-46c4-4df6-93b1-3f54385824ad
📒 Files selected for processing (4)
template/tinyvue/src/views/locale/components/add-locale.vuetemplate/tinyvue/src/views/menu/info/components/info-tab.vuetemplate/tinyvue/src/views/role/info/components/info-tab.vuetemplate/tinyvue/src/views/userManager/info/components/info-tab.vue
🚧 Files skipped from review as they are similar to previous changes (3)
- template/tinyvue/src/views/userManager/info/components/info-tab.vue
- template/tinyvue/src/views/role/info/components/info-tab.vue
- template/tinyvue/src/views/locale/components/add-locale.vue
shenjunjian
approved these changes
Jun 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
New Features
Behavior Changes
Documentation
Chores