feat(table): align table design in fe#2102
Closed
Fiona2016 wants to merge 57 commits into
Closed
Conversation
Per design-system-table.md token baseline, sorted body cells use rgb(var(--fc-fill-5-rgb) / 0.1), not the header bg (fill-2-5).
Short headers (≤4 chars) must not wrap; wide tables use horizontal scroll instead of squeezing the header.
…ob-tpls Per design-system-table.md §8: default pageSize is 15 across all tables. - alert-mutes (shield): drop defaultPageSize 30 override; inherit DEFAULT_PAGESIZE. - alert-subscribes (ListNG): drop defaultPageSize 30 override; inherit DEFAULT_PAGESIZE. - job-tpls: add 15 to pageSizeOptions so it is selectable.
Per design-system-table.md §17.3 PRD scope: - Column1Title: 订阅名称 - Column1Content: 业务组 Drop the standalone business_group column; show group as a sub-line under the subscribe name using the double-row identifier pattern (design-system §5).
…to Column1 Per design-system-table.md §17.3: - Column1Title: 规则标题 - Column1Content: 数据源类型 + 业务组 Drop the standalone business_group and cate columns; surface them as a sub-line beneath the rule title.
Per design-system-table.md §17.3: - Column1Title: 标题 - Column1Content: ID + 业务组
Per design-system-table.md §17.3: - Column1Title: 标题 - Column1Content: ID + 业务组
Per design-system-table.md §17.3: - Column1Title: 用户名 - Column1Content: 显示名 + 邮箱 + 手机号 Username keeps sorter; secondary identifiers shown beneath as text-soft.
…to Column2 Per design-system-table.md §17.3: - Column1: 状态 (kept as-is) - Column2Title: 名称 - Column2Content: 类型 (logo) + 业务组 + 级别 - Column3: 数据源 Drop standalone cate, group_id, severities columns; embed them under name. Trim defaultColumnsConfigs accordingly.
…-0509 # Conflicts: # src/pages/task/index.tsx # src/pages/taskTpl/index.tsx # src/pages/warning/shield/index.tsx
Sorted column TD was using antd default #fafafa while sorted TH inherited a different bg, making the column look split. Apply the same fc-fill-5 token to both so the whole column reads as one band. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Remove `visibility: collapse` on the rc-table measure row — Chrome treats it as collapsing layout, so MeasureCell reports offsetWidth=0 when there is no data. Combined with the recent fixed-right + scroll x:max-content rollout, empty-state tables had the first column absorb all available width. Inline `height:0; fontSize:0` on the tr already hides the row, so the rule was redundant anyway. Also flip the ping-right shadow gradient so the darker edge sits next to the fixed column instead of away from it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
src/App.less (1)
384-444: ⚡ Quick winDeduplicate table sorter overrides to a single theme source.
Line 384 through Line 444 duplicates global sorter/header override logic that is also defined in
src/theme/default.lessin this PR. Keeping both copies will drift and create precedence ambiguity; keep one canonical block (prefersrc/theme/default.less) and remove the duplicate here.As per coding guidelines, "Keep Less/CSS selectors as locally scoped as possible to avoid global style conflicts."
🤖 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 `@src/App.less` around lines 384 - 444, This file contains a duplicated Less block for table sorter/header overrides (look for selectors .ant-table-thead > tr > th, .ant-table-column-sorter, and .ant-table-column-has-sorters .ant-table-column-sorter-inner) that should be removed here and consolidated into the canonical theme source; delete the duplicated block from this file (the entire .ant-table-column-sorter/.ant-table-thead override section) and ensure only the single canonical implementation in the theme file remains, keeping selector behavior and SVG masks unchanged there to avoid precedence drift and global conflicts.src/theme/default.less (1)
270-270: ⚡ Quick winReplace hardcoded black with a theme token in danger hover color.
Line 270 mixes
var(--fc-fill-error)with#000, which introduces a magic color in theme styles. Use a theme variable for the mix target.Proposed fix
- color: color-mix(in srgb, var(--fc-fill-error) 82%, `#000`); + color: color-mix(in srgb, var(--fc-fill-error) 82%, var(--fc-text-1));As per coding guidelines, "Use color and theme-related values from
src/theme/variable.cssand existing theme system; avoid magic color values."🤖 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 `@src/theme/default.less` at line 270, The hover color currently mixes var(--fc-fill-error) with a hardcoded `#000` in the rule that sets "color: color-mix(in srgb, var(--fc-fill-error) 82%, `#000`);" — replace the magic "`#000`" with the appropriate theme token (for example var(--fc-fill-foreground) or another neutral/foreground token defined in src/theme/variable.css), update the color-mix call accordingly, and if no suitable token exists, add a descriptive token in variable.css and use that token here so the danger hover color uses only theme variables.
🤖 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 `@src/App.less`:
- Line 414: Replace the background-color value "currentColor" with the lowercase
"currentcolor" for the sorter icon color in App.less (i.e., change the
background-color: currentColor declaration to background-color: currentcolor) so
it conforms to the stylelint value-keyword-case rule.
In `@src/theme/default.less`:
- Line 293: Change the CSS keyword from the camelCase token "currentColor" to
the lowercased keyword expected by stylelint so the background-color value
conforms to the value-keyword-case rule; locate the background-color declaration
in src/theme/default.less (the line currently using background-color:
currentColor;) and replace the token with the lowercase form ("currentcolor") so
the linter no longer fails.
- Around line 113-133: The CSS hides interactive sorter/filter controls with
visibility:hidden which breaks keyboard access; update the rules for
.ant-table-column-sorter and .ant-table-filter-trigger to avoid
visibility:hidden (use only opacity and pointer events if needed) and add a
:focus-within selector in addition to :hover to reveal them (e.g., reveal on
&:hover and &:focus-within and keep the existing active selectors for
.ant-table-column-sorter-up.active/.ant-table-column-sorter-down.active/.ant-table-filter-trigger.active);
preserve the transition declarations so showing/hiding remains animated and
ensure any pointer-events or keyboard-focus styles allow keyboard users to reach
and operate the controls.
---
Nitpick comments:
In `@src/App.less`:
- Around line 384-444: This file contains a duplicated Less block for table
sorter/header overrides (look for selectors .ant-table-thead > tr > th,
.ant-table-column-sorter, and .ant-table-column-has-sorters
.ant-table-column-sorter-inner) that should be removed here and consolidated
into the canonical theme source; delete the duplicated block from this file (the
entire .ant-table-column-sorter/.ant-table-thead override section) and ensure
only the single canonical implementation in the theme file remains, keeping
selector behavior and SVG masks unchanged there to avoid precedence drift and
global conflicts.
In `@src/theme/default.less`:
- Line 270: The hover color currently mixes var(--fc-fill-error) with a
hardcoded `#000` in the rule that sets "color: color-mix(in srgb,
var(--fc-fill-error) 82%, `#000`);" — replace the magic "`#000`" with the
appropriate theme token (for example var(--fc-fill-foreground) or another
neutral/foreground token defined in src/theme/variable.css), update the
color-mix call accordingly, and if no suitable token exists, add a descriptive
token in variable.css and use that token here so the danger hover color uses
only theme variables.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4a35d91c-9b87-4965-bb49-faae06d242be
📒 Files selected for processing (7)
scripts/generate_antd_dark_less.jsscripts/generate_antd_gold_less.jssrc/App.lesssrc/theme/antd.dark.lesssrc/theme/antd.light-gold.lesssrc/theme/default.lessvite.config.ts
✅ Files skipped from review due to trivial changes (1)
- vite.config.ts
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/pages/alertCurEvent/pages/List/AlertTable.tsx (1)
305-306:⚠️ Potential issue | 🟠 Major | ⚡ Quick winPage-size defaults are not aligned with the stated table design objective.
Line 305 still sets
defaultPageSize: 30, and Line 332 omits15frompageSizeOptions. If this table is in the rollout scope, this misses the intended default behavior.Suggested fix
- defaultPageSize: 30, + defaultPageSize: 15, ... - pageSizeOptions: ['30', '100', '200', '500'], + pageSizeOptions: ['15', '30', '100', '200', '500'],Also applies to: 332-332
🤖 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 `@src/pages/alertCurEvent/pages/List/AlertTable.tsx` around lines 305 - 306, The table pagination defaults are incorrect: in AlertTable update the pagination config so defaultPageSize is 15 (not 30) and ensure the pageSizeOptions array includes 15 (e.g., [..., 15, ...]) so the default matches the selectable options; locate the pagination object where defaultPageSize and pageSizeOptions are defined and change the values there (references: defaultPageSize, pageSizeOptions in AlertTable component).
♻️ Duplicate comments (3)
src/pages/alertCurEvent/pages/List/AlertTable.tsx (1)
195-195:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFix operations column render signature to receive the row object.
Line 195 uses
render(record), but in antd Table this first argument is cell text/value. Accesses like Line 213/221/241 therefore risk reading from the wrong object at runtime. Userender(_, record).Suggested fix
- render(record) { + render(_, record) { return (Also applies to: 206-226, 241-244
🤖 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 `@src/pages/alertCurEvent/pages/List/AlertTable.tsx` at line 195, The operations column renderer in AlertTable.tsx is using the wrong parameter signature (render(record)) so it receives the cell value instead of the row object; update the render functions for the operations column(s) to accept the value placeholder and the row object (e.g., render(_, record)) wherever used (notably the render at the current function around the operations column and the other render occurrences you flagged between lines ~206-226 and ~241-244) and then adjust any references that expect the full row (e.g., accesses to record.id, record.status, etc.) to use the second parameter (record).src/theme/default.less (2)
288-288:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix CSS keyword casing for sorter icon color.
Line 288 uses
currentColor, which failsvalue-keyword-casein the provided static analysis.Suggested fix
- background-color: currentColor; + background-color: currentcolor;🤖 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 `@src/theme/default.less` at line 288, The CSS rule setting the sorter icon color uses the keyword with incorrect casing; update the background-color value from "currentColor" to the lint-expected lowercase "currentcolor" in the rule that sets the sorter icon color (i.e., the background-color property for the sorter icon in default.less) so it satisfies the value-keyword-case rule.
113-133:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAvoid hiding sorter/filter controls with
visibility: hiddenin header cells.Line 116 and Line 124/132 keep controls visibility-toggled and only reveal on hover, which risks keyboard-access regression for sorter/filter affordances. Keep opacity-based hiding and reveal on both hover and focus-within.
Suggested fix
.ant-table-column-sorter, .ant-table-filter-trigger { opacity: 0; - visibility: hidden; transition: opacity 0.2s ease, color 0.2s ease, background-color 0.2s ease; } - &:hover { + &:hover, + &:focus-within { .ant-table-column-sorter, .ant-table-filter-trigger { opacity: 1; - visibility: visible; } } .ant-table-column-sorter:has(.ant-table-column-sorter-up.active), .ant-table-column-sorter:has(.ant-table-column-sorter-down.active), .ant-table-filter-trigger.active { opacity: 1; - visibility: visible; }🤖 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 `@src/theme/default.less` around lines 113 - 133, The current rules hide .ant-table-column-sorter and .ant-table-filter-trigger using visibility: hidden which prevents keyboard focus; instead keep opacity transitions but remove visibility toggling and add focus rules so controls are revealed on both :hover and :focus-within (and when the sorter/filter has .active). Update the selectors shown (e.g., .ant-table-column-sorter, .ant-table-filter-trigger, the &:hover block, and the rules targeting :has(... .active) and .ant-table-filter-trigger.active) to not set visibility: hidden and to include :focus-within alongside :hover so keyboard users can access sorter/filter controls.
🧹 Nitpick comments (2)
src/pages/alertCurEvent/style.less (2)
166-170: ⚡ Quick winReduce selector nesting depth for tag content overflow rule.
The nested
> divunder.alert-event-tags .ant-tagexceeds the Less nesting-depth limit; prefer a dedicated class on the inner content element and target that class directly.As per coding guidelines, "Keep selectors locally scoped; limit nesting depth to ≤3 levels in Less/CSS files".
🤖 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 `@src/pages/alertCurEvent/style.less` around lines 166 - 170, The Less nesting for ".alert-event-tags .ant-tag > div" is too deep; create a dedicated class on the inner element (e.g., add a class like "tag-content" to the div inside the .ant-tag) and replace the nested selector with a direct rule targeting that class (e.g., ".alert-event-tags .ant-tag .tag-content" or simply ".tag-content") that applies overflow: hidden; white-space: nowrap; text-overflow: ellipsis; so the selector depth stays ≤3; update the template/JSX to add the new class to the inner div referenced by .ant-tag.
111-134: ⚡ Quick winMove toolbar/button layout styling to Tailwind utilities in TSX.
These new rules are direct layout/spacing/sizing styles and are better kept inline with Tailwind utility classes to avoid extra Less indirection.
As per coding guidelines, "Use Tailwind utility classes for container layout (flex, grid, gap, padding, margin, alignment)" and "Use Tailwind CSS for direct expressible styles (layout, spacing, typography, border-radius, common interaction states); avoid Tailwind for cases where it's not practical or impossible".
🤖 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 `@src/pages/alertCurEvent/style.less` around lines 111 - 134, The Less rules for .alert-event-summary-toolbar, its first child, .alert-event-expand-btn, and .ant-btn-icon should be removed and replaced by Tailwind utility classes in the TSX: give the toolbar container flex items-center justify-end gap-2, apply flex-1 min-w-0 to the left/first child element, set the expand button to flex-none w-7 h-7 p-0, and add inline-flex items-center justify-center to the icon element (ant-btn-icon) in the button; update the JSX className props accordingly and delete the matching Less selectors.
🤖 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 `@src/pages/alertCurEvent/pages/List/index.tsx`:
- Around line 330-339: The icon-only toggle Button (className
'alert-event-expand-btn') lacks accessible semantics; update the Button in this
component to include an explicit accessible name and state by adding aria-label
based on eventColumnExpanded (use the same t('common:btn.expand') /
t('common:btn.collapse') strings) and an appropriate toggle state attribute
(aria-pressed or aria-expanded) tied to eventColumnExpanded, leaving the
existing onClick handler (setEventColumnExpanded) and Tooltip intact so
assistive tech can announce the button and its current state.
In `@src/theme/default.less`:
- Line 265: Replace the hardcoded "`#000`" in the color-mix call with the proper
theme token instead of a magic value; update the rule using color-mix(in srgb,
var(--fc-fill-error) 82%, var(--fc-fill-foreground)) (or the equivalent
foreground/neutral token from src/theme/variable.css used across themes) so the
danger hover color uses theme variables and respects light/dark variants.
---
Outside diff comments:
In `@src/pages/alertCurEvent/pages/List/AlertTable.tsx`:
- Around line 305-306: The table pagination defaults are incorrect: in
AlertTable update the pagination config so defaultPageSize is 15 (not 30) and
ensure the pageSizeOptions array includes 15 (e.g., [..., 15, ...]) so the
default matches the selectable options; locate the pagination object where
defaultPageSize and pageSizeOptions are defined and change the values there
(references: defaultPageSize, pageSizeOptions in AlertTable component).
---
Duplicate comments:
In `@src/pages/alertCurEvent/pages/List/AlertTable.tsx`:
- Line 195: The operations column renderer in AlertTable.tsx is using the wrong
parameter signature (render(record)) so it receives the cell value instead of
the row object; update the render functions for the operations column(s) to
accept the value placeholder and the row object (e.g., render(_, record))
wherever used (notably the render at the current function around the operations
column and the other render occurrences you flagged between lines ~206-226 and
~241-244) and then adjust any references that expect the full row (e.g.,
accesses to record.id, record.status, etc.) to use the second parameter
(record).
In `@src/theme/default.less`:
- Line 288: The CSS rule setting the sorter icon color uses the keyword with
incorrect casing; update the background-color value from "currentColor" to the
lint-expected lowercase "currentcolor" in the rule that sets the sorter icon
color (i.e., the background-color property for the sorter icon in default.less)
so it satisfies the value-keyword-case rule.
- Around line 113-133: The current rules hide .ant-table-column-sorter and
.ant-table-filter-trigger using visibility: hidden which prevents keyboard
focus; instead keep opacity transitions but remove visibility toggling and add
focus rules so controls are revealed on both :hover and :focus-within (and when
the sorter/filter has .active). Update the selectors shown (e.g.,
.ant-table-column-sorter, .ant-table-filter-trigger, the &:hover block, and the
rules targeting :has(... .active) and .ant-table-filter-trigger.active) to not
set visibility: hidden and to include :focus-within alongside :hover so keyboard
users can access sorter/filter controls.
---
Nitpick comments:
In `@src/pages/alertCurEvent/style.less`:
- Around line 166-170: The Less nesting for ".alert-event-tags .ant-tag > div"
is too deep; create a dedicated class on the inner element (e.g., add a class
like "tag-content" to the div inside the .ant-tag) and replace the nested
selector with a direct rule targeting that class (e.g., ".alert-event-tags
.ant-tag .tag-content" or simply ".tag-content") that applies overflow: hidden;
white-space: nowrap; text-overflow: ellipsis; so the selector depth stays ≤3;
update the template/JSX to add the new class to the inner div referenced by
.ant-tag.
- Around line 111-134: The Less rules for .alert-event-summary-toolbar, its
first child, .alert-event-expand-btn, and .ant-btn-icon should be removed and
replaced by Tailwind utility classes in the TSX: give the toolbar container flex
items-center justify-end gap-2, apply flex-1 min-w-0 to the left/first child
element, set the expand button to flex-none w-7 h-7 p-0, and add inline-flex
items-center justify-center to the icon element (ant-btn-icon) in the button;
update the JSX className props accordingly and delete the matching Less
selectors.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3c5a399f-0392-4c94-8f2e-d30100cccd65
📒 Files selected for processing (10)
scripts/generate_antd_dark_less.jsscripts/generate_antd_gold_less.jssrc/pages/alertCurEvent/pages/List/AlertTable.tsxsrc/pages/alertCurEvent/pages/List/index.tsxsrc/pages/alertCurEvent/style.lesssrc/theme/antd.dark.lesssrc/theme/antd.light-blue.lesssrc/theme/antd.light-gold.lesssrc/theme/default.lessvite.config.ts
✅ Files skipped from review due to trivial changes (1)
- src/theme/antd.dark.less
🚧 Files skipped from review as they are similar to previous changes (1)
- vite.config.ts
Comment on lines
+330
to
+339
| <Tooltip title={eventColumnExpanded ? t('common:btn.collapse') : t('common:btn.expand')}> | ||
| <Button | ||
| type='text' | ||
| size='small' | ||
| className='alert-event-expand-btn' | ||
| icon={eventColumnExpanded ? <ListChevronsDownUp size={14} /> : <ListChevronsUpDown size={14} />} | ||
| onClick={() => { | ||
| setEventColumnExpanded(!eventColumnExpanded); | ||
| }} | ||
| /> |
There was a problem hiding this comment.
Add accessible semantics to the icon-only toggle button.
The expand/collapse control is icon-only, so it needs an explicit accessible name and pressed state for screen readers/assistive tech.
Proposed fix
<Button
type='text'
size='small'
className='alert-event-expand-btn'
+ aria-label={eventColumnExpanded ? t('common:btn.collapse') : t('common:btn.expand')}
+ aria-pressed={eventColumnExpanded}
icon={eventColumnExpanded ? <ListChevronsDownUp size={14} /> : <ListChevronsUpDown size={14} />}
onClick={() => {
- setEventColumnExpanded(!eventColumnExpanded);
+ setEventColumnExpanded((prev) => !prev);
}}
/>🤖 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 `@src/pages/alertCurEvent/pages/List/index.tsx` around lines 330 - 339, The
icon-only toggle Button (className 'alert-event-expand-btn') lacks accessible
semantics; update the Button in this component to include an explicit accessible
name and state by adding aria-label based on eventColumnExpanded (use the same
t('common:btn.expand') / t('common:btn.collapse') strings) and an appropriate
toggle state attribute (aria-pressed or aria-expanded) tied to
eventColumnExpanded, leaving the existing onClick handler
(setEventColumnExpanded) and Tooltip intact so assistive tech can announce the
button and its current state.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
src/pages/builtInComponents/Dashboards/index.tsx (1)
267-271:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd failure handling for payload deletion.
The delete confirm flow only handles success; request failures are currently silent.
As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/builtInComponents/Dashboards/index.tsx` around lines 267 - 271, The deletion confirm handler currently calls deletePayloads([record.id]).then(() => fetchData()) without handling failures; update the onOk handler in the component (the function named onOk) to await or attach a .catch to deletePayloads([record.id]) and handle errors (e.g., show an error notification/toast and log the error) while still refreshing via fetchData() only on success; follow existing project patterns for error handling (try/catch around the await or .catch with processLogger/notification) so failures are not silent.src/pages/warning/subscribe/ListNG.tsx (1)
308-315:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFix delete error feedback path (wrong toast type + missing rejection handling).
res.errcurrently triggersmessage.success(...), and rejected delete requests are not handled.Suggested minimal patch
onOk: () => { - deleteSubscribes({ ids: [record.id] }, record.group_id).then((res) => { - refreshList(); - if (res.err) { - message.success(res.err); - } else { - message.success(t('common:success.delete')); - } - }); + deleteSubscribes({ ids: [record.id] }, record.group_id) + .then((res) => { + if (res.err) { + message.error(res.err); + return; + } + refreshList(); + message.success(t('common:success.delete')); + }) + .catch(() => { + message.error(t('common:error.delete')); + }); },As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/warning/subscribe/ListNG.tsx` around lines 308 - 315, The delete callback misreports errors and doesn't handle promise rejections: change the flow around deleteSubscribes({ ids: [record.id] }, record.group_id) so that errors use message.error(...) (not message.success), move refreshList() to run only after a successful delete, and add proper rejection handling (either await inside try/catch or append .catch) to surface network/exception failures (use message.error(t('common:failed.delete') or the returned res.err) and optionally log the error). Ensure you update the handler around deleteSubscribes, the success/error branches that call message, and include a .catch or try/catch to handle thrown errors.src/pages/dashboard/List/index.tsx (1)
344-366:⚠️ Potential issue | 🟠 Major | ⚡ Quick winWrap action-menu async operations with explicit error handling.
Clone/delete/export handlers await async calls without a
try/catch, so failures won’t provide consistent user feedback.As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.Also applies to: 381-385
🤖 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 `@src/pages/dashboard/List/index.tsx` around lines 344 - 366, The async menu actions (cloneDashboard, delete handler, and getDashboard/Export) lack error handling; wrap each async call in a try/catch so failures show user feedback and avoid side-effects on error. For the clone flow (cloneDashboard) and the export flow (getDashboard + Export + exportDataStringify) update the onClick/onOk handlers to await inside try blocks, call message.success on success and message.error with the caught Error.message (and optionally console.error) on failure, and only call setRefreshKey or other success-only effects after the awaited call succeeds; apply the same pattern to the delete handler referenced around lines 381-385.src/pages/alertRules/List/ListNG.tsx (1)
309-313:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete failures in the operations dropdown.
deleteStrategy(...).then(...)has no rejection handling, so failed deletions are silent.As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/alertRules/List/ListNG.tsx` around lines 309 - 313, The onOk handler for the delete confirmation uses deleteStrategy([record.id], record.group_id).then(...) without handling rejections; update the onOk callback in ListNG.tsx (the function that calls deleteStrategy) to handle errors by either using async/await with try/catch or appending .catch(...) to the promise, and on failure call message.error(...) (and optionally log the error) so fetchData() is only called on success and failures surface to the user/developer instead of being silent.
♻️ Duplicate comments (4)
src/pages/notificationChannels/pages/ListNG/index.tsx (1)
323-327:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd rejection handling to the delete confirmation flow.
The delete action still only handles success; failures need explicit error feedback.
As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/notificationChannels/pages/ListNG/index.tsx` around lines 323 - 327, The onOk handler for the delete confirmation calls deleteItems([record.id]) but lacks rejection handling; update the onOk logic (the callback passed to the confirmation dialog) to handle failures by catching promise rejections from deleteItems (either with .catch(...) or by making the handler async and using try/catch), and on error call message.error(...) with a useful message (include the translated string via t(...) and/or the error.message) while preserving the success path that calls message.success(...) and run(); reference the onOk callback, deleteItems, message.success, message.error, t and run to locate and update the code.src/pages/recordingRules/PageTable.tsx (1)
243-247:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete request failures in row actions.
This delete path still only handles success; failures should surface an error message and avoid silent no-op behavior.
As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/recordingRules/PageTable.tsx` around lines 243 - 247, The onOk handler for the row delete confirmation currently calls deleteRecordingRule([record.id], record.group_id) and only handles the success case; update the onOk callback in PageTable to handle failures by attaching a .catch (or using async/await with try/catch) to deleteRecordingRule and calling message.error(...) with the error message, ensuring refreshList() is only invoked on success and not on failure. Specifically, modify the onOk closure that calls deleteRecordingRule to capture errors from deleteRecordingRule and surface them via message.error, mirroring existing async error-handling patterns used elsewhere in this file.src/pages/embeddedProduct/pages/List/index.tsx (1)
156-162:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete failures in the confirmation flow.
onOkonly handles success; failed deletes currently have no user-visible feedback and no explicit rejection handling.Suggested minimal patch
onOk: () => { - return deleteEmbeddedProducts(String(record.id)).then(() => { - message.success(t('common:success.delete')); - fetchData(); - eventBus.emit(EVENT_KEYS.EMBEDDED_PRODUCT_UPDATED); - }); + return deleteEmbeddedProducts(String(record.id)) + .then(() => { + message.success(t('common:success.delete')); + fetchData(); + eventBus.emit(EVENT_KEYS.EMBEDDED_PRODUCT_UPDATED); + }) + .catch(() => { + message.error(t('common:error.delete')); + }); },As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/embeddedProduct/pages/List/index.tsx` around lines 156 - 162, The confirmation onOk handler for deleting embedded products currently only handles the success path; update the onOk callback that calls deleteEmbeddedProducts(String(record.id)) to handle failures by adding proper error handling (e.g., chain a .catch or use try/catch if converted to async) so that on error you call message.error(...) with a meaningful message, ensure fetchData() and eventBus.emit(EVENT_KEYS.EMBEDDED_PRODUCT_UPDATED) only run on success, and propagate or return the rejected promise so the caller knows the operation failed; reference the existing onOk, deleteEmbeddedProducts, message.success, message.error, fetchData, eventBus.emit, and EVENT_KEYS.EMBEDDED_PRODUCT_UPDATED symbols when making the change.src/pages/alertRules/List/ListNG.tsx (1)
274-275:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFix operations column render signature to receive row data correctly.
render: (record: any) =>is using the first antd render arg as row data. For this column, row data must be the second arg ((_, record)), otherwiserecord.id/record.cateaccesses are invalid at runtime.#!/bin/bash # Verify operations column render signature and surrounding column shape. rg -n -C3 "title:\s*t\('common:table.operations'\)|render:\s*\(record:\s*any\)\s*=>" src/pages/alertRules/List/ListNG.tsx🤖 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 `@src/pages/alertRules/List/ListNG.tsx` around lines 274 - 275, The operations column's render callback currently uses the first antd render arg as row data (render: (record: any) => ...), causing invalid accesses like record.id and record.cate; update the render signature to accept the two-arg form (render: (_: any, record: any) => ...) and then use the second parameter (record) within the body; locate the column definition with title t('common:table.operations') and change its render to (_ , record: any) => { ... } so row data is read correctly from record for IDs/cate accesses.
🤖 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.
Outside diff comments:
In `@src/pages/alertRules/List/ListNG.tsx`:
- Around line 309-313: The onOk handler for the delete confirmation uses
deleteStrategy([record.id], record.group_id).then(...) without handling
rejections; update the onOk callback in ListNG.tsx (the function that calls
deleteStrategy) to handle errors by either using async/await with try/catch or
appending .catch(...) to the promise, and on failure call message.error(...)
(and optionally log the error) so fetchData() is only called on success and
failures surface to the user/developer instead of being silent.
In `@src/pages/builtInComponents/Dashboards/index.tsx`:
- Around line 267-271: The deletion confirm handler currently calls
deletePayloads([record.id]).then(() => fetchData()) without handling failures;
update the onOk handler in the component (the function named onOk) to await or
attach a .catch to deletePayloads([record.id]) and handle errors (e.g., show an
error notification/toast and log the error) while still refreshing via
fetchData() only on success; follow existing project patterns for error handling
(try/catch around the await or .catch with processLogger/notification) so
failures are not silent.
In `@src/pages/dashboard/List/index.tsx`:
- Around line 344-366: The async menu actions (cloneDashboard, delete handler,
and getDashboard/Export) lack error handling; wrap each async call in a
try/catch so failures show user feedback and avoid side-effects on error. For
the clone flow (cloneDashboard) and the export flow (getDashboard + Export +
exportDataStringify) update the onClick/onOk handlers to await inside try
blocks, call message.success on success and message.error with the caught
Error.message (and optionally console.error) on failure, and only call
setRefreshKey or other success-only effects after the awaited call succeeds;
apply the same pattern to the delete handler referenced around lines 381-385.
In `@src/pages/warning/subscribe/ListNG.tsx`:
- Around line 308-315: The delete callback misreports errors and doesn't handle
promise rejections: change the flow around deleteSubscribes({ ids: [record.id]
}, record.group_id) so that errors use message.error(...) (not message.success),
move refreshList() to run only after a successful delete, and add proper
rejection handling (either await inside try/catch or append .catch) to surface
network/exception failures (use message.error(t('common:failed.delete') or the
returned res.err) and optionally log the error). Ensure you update the handler
around deleteSubscribes, the success/error branches that call message, and
include a .catch or try/catch to handle thrown errors.
---
Duplicate comments:
In `@src/pages/alertRules/List/ListNG.tsx`:
- Around line 274-275: The operations column's render callback currently uses
the first antd render arg as row data (render: (record: any) => ...), causing
invalid accesses like record.id and record.cate; update the render signature to
accept the two-arg form (render: (_: any, record: any) => ...) and then use the
second parameter (record) within the body; locate the column definition with
title t('common:table.operations') and change its render to (_ , record: any) =>
{ ... } so row data is read correctly from record for IDs/cate accesses.
In `@src/pages/embeddedProduct/pages/List/index.tsx`:
- Around line 156-162: The confirmation onOk handler for deleting embedded
products currently only handles the success path; update the onOk callback that
calls deleteEmbeddedProducts(String(record.id)) to handle failures by adding
proper error handling (e.g., chain a .catch or use try/catch if converted to
async) so that on error you call message.error(...) with a meaningful message,
ensure fetchData() and eventBus.emit(EVENT_KEYS.EMBEDDED_PRODUCT_UPDATED) only
run on success, and propagate or return the rejected promise so the caller knows
the operation failed; reference the existing onOk, deleteEmbeddedProducts,
message.success, message.error, fetchData, eventBus.emit, and
EVENT_KEYS.EMBEDDED_PRODUCT_UPDATED symbols when making the change.
In `@src/pages/notificationChannels/pages/ListNG/index.tsx`:
- Around line 323-327: The onOk handler for the delete confirmation calls
deleteItems([record.id]) but lacks rejection handling; update the onOk logic
(the callback passed to the confirmation dialog) to handle failures by catching
promise rejections from deleteItems (either with .catch(...) or by making the
handler async and using try/catch), and on error call message.error(...) with a
useful message (include the translated string via t(...) and/or the
error.message) while preserving the success path that calls message.success(...)
and run(); reference the onOk callback, deleteItems, message.success,
message.error, t and run to locate and update the code.
In `@src/pages/recordingRules/PageTable.tsx`:
- Around line 243-247: The onOk handler for the row delete confirmation
currently calls deleteRecordingRule([record.id], record.group_id) and only
handles the success case; update the onOk callback in PageTable to handle
failures by attaching a .catch (or using async/await with try/catch) to
deleteRecordingRule and calling message.error(...) with the error message,
ensuring refreshList() is only invoked on success and not on failure.
Specifically, modify the onOk closure that calls deleteRecordingRule to capture
errors from deleteRecordingRule and surface them via message.error, mirroring
existing async error-handling patterns used elsewhere in this file.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3c8695fe-89ed-4b68-8879-f188540211e5
📒 Files selected for processing (7)
src/pages/alertRules/List/ListNG.tsxsrc/pages/builtInComponents/Dashboards/index.tsxsrc/pages/dashboard/List/index.tsxsrc/pages/embeddedProduct/pages/List/index.tsxsrc/pages/notificationChannels/pages/ListNG/index.tsxsrc/pages/recordingRules/PageTable.tsxsrc/pages/warning/subscribe/ListNG.tsx
Standardize all table action column Dropdowns to use `click`-only trigger and explicit `align` prop for consistent positioning. Includes minor formatting fixes (indentation, JSX simplification).
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (13)
src/pages/aiConfig/llmConfigs/pages/List.tsx (1)
118-123:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd error handling for LLM config delete action.
The confirm
onOkpath handles only success; add rejection handling and user feedback.As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/aiConfig/llmConfigs/pages/List.tsx` around lines 118 - 123, The confirm onOk handler for deleting an LLM config currently calls deleteItem(record.id).then(...) without handling failures; update the onOk to handle rejections (either convert the handler to async/await with try/catch around await deleteItem(record.id) or append .catch(...) to the promise) and show feedback on error (e.g., message.error with the error message) while preserving the success path that calls message.success and run(); ensure you reference the existing deleteItem, onOk handler, message.success, run, and record.id symbols when making the change.src/pages/builtInComponents/CollectTpls/index.tsx (1)
218-223:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete failures in collect template actions.
deletePayloadsinside confirm only executes success flow. Add.catchto surface errors and avoid silent failures.As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/builtInComponents/CollectTpls/index.tsx` around lines 218 - 223, The confirm handler calls deletePayloads([record.id]) but only handles the success path; add error handling so failures are surfaced and the success callbacks (fetchData, fetchCates) only run on success. Update the onOk handler for the confirm action (the function that calls deletePayloads) to either await deletePayloads in a try/catch or append .catch(...) to the promise; in the catch block log or show the error (e.g., using message.error or processLogger/error handler) and avoid calling fetchData()/fetchCates() when deletion fails so failures are not silently ignored.src/pages/aiConfig/mcpServers/pages/List.tsx (1)
103-108:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd failure handling for MCP server delete confirmation.
deleteItem(record.id)currently has no rejection branch inonOk.As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/aiConfig/mcpServers/pages/List.tsx` around lines 103 - 108, The delete confirmation's onOk handler calls deleteItem(record.id) but lacks error handling; update the onOk callback in List.tsx to handle rejection from deleteItem (e.g., attach a .catch or use async/try-catch) so failures show a user-facing message and avoid silent failures — call message.error with a localized error string (using t) and optionally log the error, while keeping the success path (message.success and run()) intact; reference the onOk handler, deleteItem, run, and message.success/message.error to find where to add the catch/try-catch.src/pages/metricsBuiltin/List.tsx (1)
320-327:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd error handling to row delete confirm flow.
Line 323 only handles success; failed deletes are silent and don’t surface feedback.
Proposed fix
Modal.confirm({ title: t('common:confirm.delete'), - onOk() { - deleteMetrics([record.id]).then(() => { - message.success(t('common:success.delete')); - setRefreshFlag(_.uniqueId('refreshFlag_')); - }); + onOk: async () => { + try { + await deleteMetrics([record.id]); + message.success(t('common:success.delete')); + setRefreshFlag(_.uniqueId('refreshFlag_')); + } catch (err: any) { + message.error(err?.message || t('common:failure.delete')); + return Promise.reject(err); + } }, });As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.🤖 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 `@src/pages/metricsBuiltin/List.tsx` around lines 320 - 327, The Modal.confirm onOk currently calls deleteMetrics([record.id]) and only handles success; update the onOk handler (Modal.confirm's onOk) to handle errors too by either making onOk async with try/catch or attaching a .catch to deleteMetrics([record.id]); on success call message.success and setRefreshFlag(_.uniqueId('refreshFlag_')), on failure call message.error with a user-friendly localized message (e.g., t('common:failed.delete')) and/or include the error details for logging—ensure deleteMetrics, message.success, message.error, setRefreshFlag, _.uniqueId and record.id are used appropriately and that refresh is only triggered on success.src/pages/aiConfig/agents/pages/List.tsx (1)
88-95:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle failures for enable toggle and delete actions.
Both mutation paths currently assume success; failed requests won’t show feedback and may desync UI state.
Proposed fix
onChange={(checked) => { - putItem(record.id, { - ...record, - enabled: checked, - }).then(() => { - message.success(t('common:success.modify')); - run(); - }); + putItem(record.id, { + ...record, + enabled: checked, + }) + .then(() => { + message.success(t('common:success.modify')); + run(); + }) + .catch((err) => { + message.error(err?.message || t('common:failure.modify')); + }); }} @@ onOk: () => { - deleteItem(record.id).then(() => { - message.success(t('common:success.delete')); - run(); - }); + deleteItem(record.id) + .then(() => { + message.success(t('common:success.delete')); + run(); + }) + .catch((err) => { + message.error(err?.message || t('common:failure.delete')); + }); },As per coding guidelines,
src/**/*.{ts,tsx}: Async requests must include error handling (try/catch,.catch,onError, etc.) consistent with existing patterns.Also applies to: 135-140
🤖 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 `@src/pages/aiConfig/agents/pages/List.tsx` around lines 88 - 95, The enable-toggle and delete mutation calls (the putItem(...) promise and the delete path around lines referencing putItem, run, and message.success) lack error handling and assume success; wrap these async operations with proper error handling (use .catch or async/await with try/catch) and on error call message.error with a helpful localized message, avoid leaving the UI in the optimistic state by reverting any local changes or re-running run() only on success, and ensure the delete handler does the same (handle errors for the delete function referenced near lines 135-140) so failures surface to the user and the UI stays consistent.src/pages/builtInComponents/AlertRules/index.tsx (1)
312-317:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDelete action should handle request failures.
deletePayloads([record.id]).then(...)is success-only; add a rejection path and keep refresh calls in the success path.As per coding guidelines, "Async requests must include error handling (`try/catch`, `.catch`, `onError`, etc.) consistent with existing patterns".Suggested patch
onOk() { - deletePayloads([record.id]).then(() => { - fetchData(); - fetchCates(); - }); + return deletePayloads([record.id]) + .then(() => { + fetchData(); + fetchCates(); + message.success(t('common:success.delete')); + }) + .catch((err) => { + message.error(err?.message || t('common:error.delete')); + return Promise.reject(err); + }); },🤖 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 `@src/pages/builtInComponents/AlertRules/index.tsx` around lines 312 - 317, The delete handler currently calls deletePayloads([record.id]).then(...) without handling failures; update the onOk() implementation for the delete action so that the refresh calls (fetchData and fetchCates) only run on successful deletion and errors are handled—either by appending a .catch(...) to deletePayloads(...) to log or surface the error (and avoid calling fetchData/fetchCates), or by using async/await with try/catch inside onOk to call deletePayloads and then on success call fetchData() and fetchCates(), and in the catch block handle/report the error consistently with existing patterns.src/pages/aiConfig/skills/pages/ResourcesTable.tsx (1)
177-182:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete failures in the row action flow.
Line 178 only handles success. Add a rejection path so users get feedback and
run()is not called on failure.As per coding guidelines, "Async requests must include error handling (`try/catch`, `.catch`, `onError`, etc.) consistent with existing patterns".Suggested patch
onOk: () => { - deleteFile(record.id).then(() => { - message.success(t('common:success.delete')); - run(); - }); + return deleteFile(record.id) + .then(() => { + message.success(t('common:success.delete')); + run(); + }) + .catch((err) => { + message.error(err?.message || t('common:error.delete')); + return Promise.reject(err); + }); },🤖 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 `@src/pages/aiConfig/skills/pages/ResourcesTable.tsx` around lines 177 - 182, The delete confirmation's onOk currently calls deleteFile(record.id) and only handles the success path; update it to handle failures by adding a rejection handler (e.g., .catch or try/catch if converted to async) so that on error you call message.error(...) with the error or a translated message and do not call run(); ensure the onOk flow references deleteFile(record.id) and run() so the success path still shows message.success(...) and calls run(), while any rejection displays the error feedback and prevents run() from executing.src/pages/user/users.tsx (1)
167-170:⚠️ Potential issue | 🟠 Major | ⚡ Quick winUser delete action needs rejection handling.
The current
deleteUser(record.id).then(...)flow has no error branch, so delete failures are silent.As per coding guidelines, "Async requests must include error handling (`try/catch`, `.catch`, `onError`, etc.) consistent with existing patterns".Suggested patch
onOk: () => { - deleteUser(record.id).then((_) => { - message.success(t('common:success.delete')); - handleClose(); - }); + return deleteUser(record.id) + .then(() => { + message.success(t('common:success.delete')); + handleClose(); + }) + .catch((err) => { + message.error(err?.message || t('common:error.delete')); + return Promise.reject(err); + }); },🤖 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 `@src/pages/user/users.tsx` around lines 167 - 170, The deleteUser call currently only handles the success path and swallows failures; update the delete flow in users.tsx (the deleteUser(record.id) invocation) to handle rejections by adding an error branch (either append .catch(...) to the promise or convert the handler to async/await with try/catch) that calls message.error(...) with a useful localized error message and logs the error, and ensure handleClose() is only called on success or that failures leave the UI in a consistent state.src/pages/builtInComponents/Dashboards/index.tsx (2)
267-271:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete failures in modal
onOk.
deletePayloads(...).then(...)only handles success and misses user feedback on failure.Proposed fix
- onOk() { - deletePayloads([record.id]).then(() => { - fetchData(); - }); - }, + async onOk() { + try { + await deletePayloads([record.id]); + fetchData(); + } catch (err) { + message.error(t('common:failed.delete')); + return Promise.reject(err); + } + },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/builtInComponents/Dashboards/index.tsx` around lines 267 - 271, The modal onOk handler currently calls deletePayloads([record.id]).then(() => fetchData()) with no error handling; update the onOk (or the function containing it) to await or attach a .catch to deletePayloads([record.id]) and handle failures by showing user feedback (e.g., message.error or notification.error) and ensuring any UI state (modal loading/visibility) is updated appropriately, while preserving the success path that calls fetchData() and shows success feedback; reference the onOk handler, deletePayloads, and fetchData to locate and modify the code.
200-214:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFix AntD Table render callback signature in operations column.
The render function receives three parameters
(value, record, index), but the current code only accepts one and names itrecord. This captures the cell value (first parameter) instead of the row record object, causingrecord.content,record.updated_by, andrecord.idto be undefined at runtime.Proposed fix
- render: (record) => { + render: (_, record) => { return (🤖 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 `@src/pages/builtInComponents/Dashboards/index.tsx` around lines 200 - 214, The Table column's render callback currently declares a single parameter named record but actually receives (value, record, index), so the code is reading the cell value instead of the row object; update the render signature to accept the standard parameters (value, record, index) or use (_, record) if you only need the row, then update usages in this callback (references to record.content, record.updated_by, record.id used by Import, formatBeautifyJson, TableActionButton handlers, etc.) to use the correct record parameter so those fields are defined at runtime.src/pages/alertRules/List/ListNG.tsx (1)
309-313:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle delete request failures in
Modal.confirmaction.
deleteStrategy(...).then(...)has no failure path, so errors are silent and users get no feedback.Proposed fix
- onOk: () => { - deleteStrategy([record.id], record.group_id).then(() => { - message.success(t('common:success.delete')); - fetchData(); - }); - }, + onOk: async () => { + try { + await deleteStrategy([record.id], record.group_id); + message.success(t('common:success.delete')); + fetchData(); + } catch (err) { + message.error(t('common:failed.delete')); + return Promise.reject(err); + } + },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/alertRules/List/ListNG.tsx` around lines 309 - 313, The Modal.confirm onOk currently calls deleteStrategy([record.id], record.group_id).then(...) with no failure handling, so failures are silent; update the onOk handler (the Modal.confirm callback that calls deleteStrategy) to handle errors either by using async/await with try/catch or by adding a .catch handler to the promise returned by deleteStrategy, and on error call message.error with a descriptive message (and optionally log the error) while preserving the success branch that calls message.success and fetchData; ensure you reference the same identifiers (deleteStrategy, record.id, record.group_id, message.success, message.error, fetchData) so error feedback is shown to users.src/pages/dashboard/List/index.tsx (1)
344-365:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd explicit failure handling for operations menu async actions.
Clone/export/delete calls run without
try/catch, so users may get no actionable feedback on failure.As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".Also applies to: 381-385
🤖 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 `@src/pages/dashboard/List/index.tsx` around lines 344 - 365, The menu action callbacks (the clone flow using cloneDashboard in the onOk callback and the export flow using getDashboard/Export) lack error handling; wrap these async operations in try/catch blocks (and any similar async handlers around lines ~381-385) so failures call message.error(...) with a helpful localized message and optional logging, and only call message.success(...) and setRefreshKey(...) on success; ensure the same pattern is applied to delete/export/clone handlers (functions referenced: cloneDashboard, getDashboard, Export, setRefreshKey, message.success) so users receive clear feedback on errors.src/pages/warning/subscribe/ListNG.tsx (1)
308-315:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFix delete error path and add rejection handling.
res.errcurrently shows viamessage.success, and rejected requests are not caught.Proposed fix
- onOk: () => { - deleteSubscribes({ ids: [record.id] }, record.group_id).then((res) => { - refreshList(); - if (res.err) { - message.success(res.err); - } else { - message.success(t('common:success.delete')); - } - }); - }, + onOk: async () => { + try { + const res = await deleteSubscribes({ ids: [record.id] }, record.group_id); + if (res.err) { + message.error(res.err); + return Promise.reject(new Error(res.err)); + } + message.success(t('common:success.delete')); + refreshList(); + } catch (err) { + message.error(t('common:failed.delete')); + return Promise.reject(err); + } + },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/warning/subscribe/ListNG.tsx` around lines 308 - 315, The delete handler incorrectly shows errors as success and lacks rejection handling; update the deleteSubscribes call so it treats res.err as an error (use message.error) and only calls refreshList on successful deletion, and add a .catch to handle promise rejections (displaying err.message or String(err) via message.error). Locate the block that calls deleteSubscribes({ ids: [record.id] }, record.group_id) and replace the callback with logic that checks if (res.err) -> message.error(...), else -> message.success(t('common:success.delete')) and refreshList(), plus append .catch(err => message.error(err.message || String(err))).
♻️ Duplicate comments (8)
src/pages/variableConfigs/index.tsx (1)
173-177:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd error handling to variable-config delete confirmation.
onOkcurrently handles only success; rejected deletes fail silently.Suggested fix
onOk: () => { - deleteVariableConfigs(record.id).then(() => { + return deleteVariableConfigs(record.id).then(() => { message.success(t('common:success.delete')); fetchData(); + }).catch((err) => { + message.error(err?.message || t('common:request_failed')); + return Promise.reject(err); }); },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/variableConfigs/index.tsx` around lines 173 - 177, The delete confirmation's onOk currently calls deleteVariableConfigs(record.id) without handling rejections; update the onOk handler to catch errors from deleteVariableConfigs (either by making onOk async and using try/catch around await deleteVariableConfigs(record.id) or by appending .catch(...) to the promise), show an error message via message.error (using t for localization) on failure, and keep the existing success path (message.success and fetchData()) in the success branch; reference the onOk callback, deleteVariableConfigs, record.id, message.success, message.error, t, and fetchData when making the change.src/pages/user/business.tsx (1)
98-102:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle
deleteBusinessTeamMemberfailure path in confirm callback.The current flow only handles success. Add catch/try-catch and show an error on failure.
As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/user/business.tsx` around lines 98 - 102, The confirm onOk callback currently calls deleteBusinessTeamMember(teamId, params) and only handles the success path; wrap the async call in a try/catch (or append .catch) so failures are handled: call message.error(...) with a clear failure message and optionally log the error, and ensure getTeamList() only runs on success; update the onOk handler around deleteBusinessTeamMember and getTeamList to reflect this error handling.src/pages/notificationRules/pages/List.tsx (2)
218-220:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAlign operations edit route with
IS_PLUSbehavior.This menu item always routes to
/${NS}/edit/${record.id}while the name link already branches for PLUS mode.Suggested fix
-<TableActionLink actionIcon='edit' to={{ pathname: `/${NS}/edit/${record.id}` }}> +<TableActionLink + actionIcon='edit' + to={{ pathname: IS_PLUS ? `/${NS}/detail/${record.id}` : `/${NS}/edit/${record.id}` }} +>🤖 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 `@src/pages/notificationRules/pages/List.tsx` around lines 218 - 220, The edit menu item always links to `/${NS}/edit/${record.id}` but must follow the same IS_PLUS branching as the name link; update the TableActionLink (in List.tsx) to build its `to`/pathname using the same conditional/utility used by the name link (check the name link's implementation and the IS_PLUS flag) so that when IS_PLUS is true it navigates to the PLUS-specific route and otherwise to the standard `edit` route, keeping the route variable references (NS, record.id) consistent.
235-238:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd error handling to notification-rule delete action.
The delete confirm
onOkonly implements success flow; rejected requests are unhandled.As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/notificationRules/pages/List.tsx` around lines 235 - 238, The onOk handler for the delete confirm currently calls deleteItems([record.id]).then(() => fetchData()) with no error handling; wrap the async call in a try/catch (or add a .catch) so rejections are handled: call deleteItems([record.id]) inside an async function or promise chain, on success call fetchData(), on error log the error and surface it to the user (e.g., message.error or notification.error) and clear any loading state. Update the onOk callback that references deleteItems and fetchData to follow the existing error-handling pattern used elsewhere in this file.src/pages/datasource/components/TableSource/index.tsx (1)
209-216:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHandle failed datasource mutations in the action menu.
Both status toggle and delete only implement success paths. Add rejection handling so failures are visible and refresh only occurs on success.
Suggested fix
onConfirm={() => { - updateDataSourceStatus({ + return updateDataSourceStatus({ id: record.id, status: record.status === 'enabled' ? 'disabled' : 'enabled', }).then(() => { message.success(record.status === 'enabled' ? t('success.disable') : t('success.enable')); setRefresh((oldVal) => !oldVal); + }).catch((err) => { + message.error(err?.message || t('common:request_failed')); + return Promise.reject(err); }); }} onOk() { - deleteDataSourceById(record.id).then(() => { + return deleteDataSourceById(record.id).then(() => { message.success(t('common:success.delete')); setRefresh((oldVal) => !oldVal); + }).catch((err) => { + message.error(err?.message || t('common:request_failed')); + return Promise.reject(err); }); },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".Also applies to: 238-241
🤖 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 `@src/pages/datasource/components/TableSource/index.tsx` around lines 209 - 216, The status-toggle and delete actions call updateDataSourceStatus and deleteDataSource but only handle the success path; wrap these async calls with proper rejection handling (use .catch or async/await try/catch) so failures show a visible error (call message.error with a descriptive message and the error) and ensure setRefresh((old) => !old) is only invoked on successful completion; target the updateDataSourceStatus and deleteDataSource call sites and ensure you use record.id/record.status for context in the messages.src/pages/alertRules/List/ListNG.tsx (1)
274-276:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFix operations column
rendercallback signature to receive the row record.The callback currently treats the first argument as the row object, so
record.id/record.cateaccess can break at runtime.Proposed fix
- render: (record: any) => { + render: (_: unknown, record: AlertRuleType<any>) => { const anomalyEnabled = _.get(record, ['rule_config', 'anomaly_trigger', 'enable']);🤖 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 `@src/pages/alertRules/List/ListNG.tsx` around lines 274 - 276, The operations column's render callback currently declares a single parameter (render: (record: any) => { ... }) but Ant Design table passes (text, record, index), so the row object should be taken from the second parameter; change the signature to accept (text, record) or (value, record, index) and update all uses inside the callback (e.g., accesses like record.id, record.cate, _.get(record, [...])) to reference the second parameter `record` rather than the first positional arg; update the render declaration (the function used in the column definition) accordingly so runtime lookups for record.id and record.cate work correctly.src/pages/taskTpl/index.tsx (1)
196-203:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd explicit error handling to template deletion
onOk.Current promise chain handles only success, so request failures are not handled deterministically.
Proposed fix
- onOk: () => { - return request(`${api.tasktpl(record.group_id)}/${record.id}`, { - method: 'DELETE', - }).then(() => { - message.success(t('msg.delete.success')); - refresh(); - }); - }, + onOk: async () => { + try { + await request(`${api.tasktpl(record.group_id)}/${record.id}`, { + method: 'DELETE', + }); + message.success(t('msg.delete.success')); + refresh(); + } catch (err) { + message.error(t('common:failed.delete')); + return Promise.reject(err); + } + },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/taskTpl/index.tsx` around lines 196 - 203, The onOk handler for template deletion currently only handles the success path; wrap the request call in proper error handling so failures are handled deterministically: in the onOk of the delete confirm, call request(`${api.tasktpl(record.group_id)}/${record.id}`, { method: 'DELETE' }) and add a .catch (or use async/await with try/catch) to log or surface the error (e.g., message.error with the error message) and ensure refresh() is only called on success; reference the onOk handler, request function, api.tasktpl(...) and refresh() when locating where to add this handling.src/pages/recordingRules/PageTable.tsx (1)
244-247:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd failure handling for row delete action.
The delete flow still only handles success; failures are not surfaced.
Proposed fix
- onOk: () => { - deleteRecordingRule([record.id], record.group_id).then(() => { - message.success(t('common:success.delete')); - refreshList(); - }); - }, + onOk: async () => { + try { + await deleteRecordingRule([record.id], record.group_id); + message.success(t('common:success.delete')); + refreshList(); + } catch (err) { + message.error(t('common:failed.delete')); + return Promise.reject(err); + } + },As per coding guidelines, "Async requests must include error handling (
try/catch,.catch,onError, etc.) consistent with existing patterns".🤖 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 `@src/pages/recordingRules/PageTable.tsx` around lines 244 - 247, The deleteRecordingRule call in the row delete handler currently only handles success and lacks failure handling; update the async flow around deleteRecordingRule([record.id], record.group_id) to catch errors (use .catch or async/try-catch) and on failure call message.error(...) with an appropriate translated error message and optionally log the error, while preserving the existing message.success(...) and refreshList() on success; ensure you reference the same identifiers (deleteRecordingRule, record.id, record.group_id, message.success, refreshList) so the behavior is consistent with other async request patterns in the codebase.
🤖 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 `@src/pages/builtInComponents/Metrics/index.tsx`:
- Around line 199-203: The single-row delete call using
deleteMetrics([record.id]) currently only handles success; add error handling so
failures show feedback and do not refresh. Wrap the delete call in a proper
.catch (or convert to async/await with try/catch) around the promise returned by
deleteMetrics in the same block where message.success(...) and
setRefreshFlag(_.uniqueId('refreshFlag_')) are used; on error call
message.error(...) with an appropriate translated message (use t('common:...')
or include err.message) and avoid calling setRefreshFlag when the delete fails.
Ensure you reference deleteMetrics, message.success, message.error,
setRefreshFlag and _.uniqueId in the fix.
---
Outside diff comments:
In `@src/pages/aiConfig/agents/pages/List.tsx`:
- Around line 88-95: The enable-toggle and delete mutation calls (the
putItem(...) promise and the delete path around lines referencing putItem, run,
and message.success) lack error handling and assume success; wrap these async
operations with proper error handling (use .catch or async/await with try/catch)
and on error call message.error with a helpful localized message, avoid leaving
the UI in the optimistic state by reverting any local changes or re-running
run() only on success, and ensure the delete handler does the same (handle
errors for the delete function referenced near lines 135-140) so failures
surface to the user and the UI stays consistent.
In `@src/pages/aiConfig/llmConfigs/pages/List.tsx`:
- Around line 118-123: The confirm onOk handler for deleting an LLM config
currently calls deleteItem(record.id).then(...) without handling failures;
update the onOk to handle rejections (either convert the handler to async/await
with try/catch around await deleteItem(record.id) or append .catch(...) to the
promise) and show feedback on error (e.g., message.error with the error message)
while preserving the success path that calls message.success and run(); ensure
you reference the existing deleteItem, onOk handler, message.success, run, and
record.id symbols when making the change.
In `@src/pages/aiConfig/mcpServers/pages/List.tsx`:
- Around line 103-108: The delete confirmation's onOk handler calls
deleteItem(record.id) but lacks error handling; update the onOk callback in
List.tsx to handle rejection from deleteItem (e.g., attach a .catch or use
async/try-catch) so failures show a user-facing message and avoid silent
failures — call message.error with a localized error string (using t) and
optionally log the error, while keeping the success path (message.success and
run()) intact; reference the onOk handler, deleteItem, run, and
message.success/message.error to find where to add the catch/try-catch.
In `@src/pages/aiConfig/skills/pages/ResourcesTable.tsx`:
- Around line 177-182: The delete confirmation's onOk currently calls
deleteFile(record.id) and only handles the success path; update it to handle
failures by adding a rejection handler (e.g., .catch or try/catch if converted
to async) so that on error you call message.error(...) with the error or a
translated message and do not call run(); ensure the onOk flow references
deleteFile(record.id) and run() so the success path still shows
message.success(...) and calls run(), while any rejection displays the error
feedback and prevents run() from executing.
In `@src/pages/alertRules/List/ListNG.tsx`:
- Around line 309-313: The Modal.confirm onOk currently calls
deleteStrategy([record.id], record.group_id).then(...) with no failure handling,
so failures are silent; update the onOk handler (the Modal.confirm callback that
calls deleteStrategy) to handle errors either by using async/await with
try/catch or by adding a .catch handler to the promise returned by
deleteStrategy, and on error call message.error with a descriptive message (and
optionally log the error) while preserving the success branch that calls
message.success and fetchData; ensure you reference the same identifiers
(deleteStrategy, record.id, record.group_id, message.success, message.error,
fetchData) so error feedback is shown to users.
In `@src/pages/builtInComponents/AlertRules/index.tsx`:
- Around line 312-317: The delete handler currently calls
deletePayloads([record.id]).then(...) without handling failures; update the
onOk() implementation for the delete action so that the refresh calls (fetchData
and fetchCates) only run on successful deletion and errors are handled—either by
appending a .catch(...) to deletePayloads(...) to log or surface the error (and
avoid calling fetchData/fetchCates), or by using async/await with try/catch
inside onOk to call deletePayloads and then on success call fetchData() and
fetchCates(), and in the catch block handle/report the error consistently with
existing patterns.
In `@src/pages/builtInComponents/CollectTpls/index.tsx`:
- Around line 218-223: The confirm handler calls deletePayloads([record.id]) but
only handles the success path; add error handling so failures are surfaced and
the success callbacks (fetchData, fetchCates) only run on success. Update the
onOk handler for the confirm action (the function that calls deletePayloads) to
either await deletePayloads in a try/catch or append .catch(...) to the promise;
in the catch block log or show the error (e.g., using message.error or
processLogger/error handler) and avoid calling fetchData()/fetchCates() when
deletion fails so failures are not silently ignored.
In `@src/pages/builtInComponents/Dashboards/index.tsx`:
- Around line 267-271: The modal onOk handler currently calls
deletePayloads([record.id]).then(() => fetchData()) with no error handling;
update the onOk (or the function containing it) to await or attach a .catch to
deletePayloads([record.id]) and handle failures by showing user feedback (e.g.,
message.error or notification.error) and ensuring any UI state (modal
loading/visibility) is updated appropriately, while preserving the success path
that calls fetchData() and shows success feedback; reference the onOk handler,
deletePayloads, and fetchData to locate and modify the code.
- Around line 200-214: The Table column's render callback currently declares a
single parameter named record but actually receives (value, record, index), so
the code is reading the cell value instead of the row object; update the render
signature to accept the standard parameters (value, record, index) or use (_,
record) if you only need the row, then update usages in this callback
(references to record.content, record.updated_by, record.id used by Import,
formatBeautifyJson, TableActionButton handlers, etc.) to use the correct record
parameter so those fields are defined at runtime.
In `@src/pages/dashboard/List/index.tsx`:
- Around line 344-365: The menu action callbacks (the clone flow using
cloneDashboard in the onOk callback and the export flow using
getDashboard/Export) lack error handling; wrap these async operations in
try/catch blocks (and any similar async handlers around lines ~381-385) so
failures call message.error(...) with a helpful localized message and optional
logging, and only call message.success(...) and setRefreshKey(...) on success;
ensure the same pattern is applied to delete/export/clone handlers (functions
referenced: cloneDashboard, getDashboard, Export, setRefreshKey,
message.success) so users receive clear feedback on errors.
In `@src/pages/metricsBuiltin/List.tsx`:
- Around line 320-327: The Modal.confirm onOk currently calls
deleteMetrics([record.id]) and only handles success; update the onOk handler
(Modal.confirm's onOk) to handle errors too by either making onOk async with
try/catch or attaching a .catch to deleteMetrics([record.id]); on success call
message.success and setRefreshFlag(_.uniqueId('refreshFlag_')), on failure call
message.error with a user-friendly localized message (e.g.,
t('common:failed.delete')) and/or include the error details for logging—ensure
deleteMetrics, message.success, message.error, setRefreshFlag, _.uniqueId and
record.id are used appropriately and that refresh is only triggered on success.
In `@src/pages/user/users.tsx`:
- Around line 167-170: The deleteUser call currently only handles the success
path and swallows failures; update the delete flow in users.tsx (the
deleteUser(record.id) invocation) to handle rejections by adding an error branch
(either append .catch(...) to the promise or convert the handler to async/await
with try/catch) that calls message.error(...) with a useful localized error
message and logs the error, and ensure handleClose() is only called on success
or that failures leave the UI in a consistent state.
In `@src/pages/warning/subscribe/ListNG.tsx`:
- Around line 308-315: The delete handler incorrectly shows errors as success
and lacks rejection handling; update the deleteSubscribes call so it treats
res.err as an error (use message.error) and only calls refreshList on successful
deletion, and add a .catch to handle promise rejections (displaying err.message
or String(err) via message.error). Locate the block that calls
deleteSubscribes({ ids: [record.id] }, record.group_id) and replace the callback
with logic that checks if (res.err) -> message.error(...), else ->
message.success(t('common:success.delete')) and refreshList(), plus append
.catch(err => message.error(err.message || String(err))).
---
Duplicate comments:
In `@src/pages/alertRules/List/ListNG.tsx`:
- Around line 274-276: The operations column's render callback currently
declares a single parameter (render: (record: any) => { ... }) but Ant Design
table passes (text, record, index), so the row object should be taken from the
second parameter; change the signature to accept (text, record) or (value,
record, index) and update all uses inside the callback (e.g., accesses like
record.id, record.cate, _.get(record, [...])) to reference the second parameter
`record` rather than the first positional arg; update the render declaration
(the function used in the column definition) accordingly so runtime lookups for
record.id and record.cate work correctly.
In `@src/pages/datasource/components/TableSource/index.tsx`:
- Around line 209-216: The status-toggle and delete actions call
updateDataSourceStatus and deleteDataSource but only handle the success path;
wrap these async calls with proper rejection handling (use .catch or async/await
try/catch) so failures show a visible error (call message.error with a
descriptive message and the error) and ensure setRefresh((old) => !old) is only
invoked on successful completion; target the updateDataSourceStatus and
deleteDataSource call sites and ensure you use record.id/record.status for
context in the messages.
In `@src/pages/notificationRules/pages/List.tsx`:
- Around line 218-220: The edit menu item always links to
`/${NS}/edit/${record.id}` but must follow the same IS_PLUS branching as the
name link; update the TableActionLink (in List.tsx) to build its `to`/pathname
using the same conditional/utility used by the name link (check the name link's
implementation and the IS_PLUS flag) so that when IS_PLUS is true it navigates
to the PLUS-specific route and otherwise to the standard `edit` route, keeping
the route variable references (NS, record.id) consistent.
- Around line 235-238: The onOk handler for the delete confirm currently calls
deleteItems([record.id]).then(() => fetchData()) with no error handling; wrap
the async call in a try/catch (or add a .catch) so rejections are handled: call
deleteItems([record.id]) inside an async function or promise chain, on success
call fetchData(), on error log the error and surface it to the user (e.g.,
message.error or notification.error) and clear any loading state. Update the
onOk callback that references deleteItems and fetchData to follow the existing
error-handling pattern used elsewhere in this file.
In `@src/pages/recordingRules/PageTable.tsx`:
- Around line 244-247: The deleteRecordingRule call in the row delete handler
currently only handles success and lacks failure handling; update the async flow
around deleteRecordingRule([record.id], record.group_id) to catch errors (use
.catch or async/try-catch) and on failure call message.error(...) with an
appropriate translated error message and optionally log the error, while
preserving the existing message.success(...) and refreshList() on success;
ensure you reference the same identifiers (deleteRecordingRule, record.id,
record.group_id, message.success, refreshList) so the behavior is consistent
with other async request patterns in the codebase.
In `@src/pages/taskTpl/index.tsx`:
- Around line 196-203: The onOk handler for template deletion currently only
handles the success path; wrap the request call in proper error handling so
failures are handled deterministically: in the onOk of the delete confirm, call
request(`${api.tasktpl(record.group_id)}/${record.id}`, { method: 'DELETE' })
and add a .catch (or use async/await with try/catch) to log or surface the error
(e.g., message.error with the error message) and ensure refresh() is only called
on success; reference the onOk handler, request function, api.tasktpl(...) and
refresh() when locating where to add this handling.
In `@src/pages/user/business.tsx`:
- Around line 98-102: The confirm onOk callback currently calls
deleteBusinessTeamMember(teamId, params) and only handles the success path; wrap
the async call in a try/catch (or append .catch) so failures are handled: call
message.error(...) with a clear failure message and optionally log the error,
and ensure getTeamList() only runs on success; update the onOk handler around
deleteBusinessTeamMember and getTeamList to reflect this error handling.
In `@src/pages/variableConfigs/index.tsx`:
- Around line 173-177: The delete confirmation's onOk currently calls
deleteVariableConfigs(record.id) without handling rejections; update the onOk
handler to catch errors from deleteVariableConfigs (either by making onOk async
and using try/catch around await deleteVariableConfigs(record.id) or by
appending .catch(...) to the promise), show an error message via message.error
(using t for localization) on failure, and keep the existing success path
(message.success and fetchData()) in the success branch; reference the onOk
callback, deleteVariableConfigs, record.id, message.success, message.error, t,
and fetchData when making the change.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2b920ae9-4687-4246-982e-ecb3ec5fc8ee
📒 Files selected for processing (31)
src/pages/aiConfig/agents/pages/List.tsxsrc/pages/aiConfig/llmConfigs/pages/List.tsxsrc/pages/aiConfig/mcpServers/pages/List.tsxsrc/pages/aiConfig/skills/pages/ResourcesTable.tsxsrc/pages/alertCurEvent/pages/List/AlertTable.tsxsrc/pages/alertRules/List/ListNG.tsxsrc/pages/builtInComponents/AlertRules/index.tsxsrc/pages/builtInComponents/CollectTpls/index.tsxsrc/pages/builtInComponents/Dashboards/index.tsxsrc/pages/builtInComponents/Metrics/index.tsxsrc/pages/dashboard/List/index.tsxsrc/pages/datasource/components/TableSource/index.tsxsrc/pages/embeddedProduct/pages/List/index.tsxsrc/pages/event/Table.tsxsrc/pages/event/card.tsxsrc/pages/eventPipeline/pages/List/index.tsxsrc/pages/historyEvents/ListNG/index.tsxsrc/pages/log/IndexPatterns/index.tsxsrc/pages/metricsBuiltin/List.tsxsrc/pages/notificationChannels/pages/List/index.tsxsrc/pages/notificationChannels/pages/ListNG/index.tsxsrc/pages/notificationRules/pages/List.tsxsrc/pages/recordingRules/PageTable.tsxsrc/pages/task/index.tsxsrc/pages/taskTpl/index.tsxsrc/pages/user/business.tsxsrc/pages/user/groups.tsxsrc/pages/user/users.tsxsrc/pages/variableConfigs/index.tsxsrc/pages/warning/shield/index.tsxsrc/pages/warning/subscribe/ListNG.tsx
Comment on lines
+199
to
+203
| deleteMetrics([record.id]).then(() => { | ||
| message.success(t('common:success.delete')); | ||
| setRefreshFlag(_.uniqueId('refreshFlag_')); | ||
| }); | ||
| }, |
There was a problem hiding this comment.
Add failure handling for single-row delete.
This delete path is success-only; failed requests currently produce no user feedback.
Suggested patch
onOk() {
- deleteMetrics([record.id]).then(() => {
- message.success(t('common:success.delete'));
- setRefreshFlag(_.uniqueId('refreshFlag_'));
- });
+ return deleteMetrics([record.id])
+ .then(() => {
+ message.success(t('common:success.delete'));
+ setRefreshFlag(_.uniqueId('refreshFlag_'));
+ })
+ .catch((err) => {
+ message.error(err?.message || t('common:error.delete'));
+ return Promise.reject(err);
+ });
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| deleteMetrics([record.id]).then(() => { | |
| message.success(t('common:success.delete')); | |
| setRefreshFlag(_.uniqueId('refreshFlag_')); | |
| }); | |
| }, | |
| onOk() { | |
| return deleteMetrics([record.id]) | |
| .then(() => { | |
| message.success(t('common:success.delete')); | |
| setRefreshFlag(_.uniqueId('refreshFlag_')); | |
| }) | |
| .catch((err) => { | |
| message.error(err?.message || t('common:error.delete')); | |
| return Promise.reject(err); | |
| }); | |
| }, |
🤖 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 `@src/pages/builtInComponents/Metrics/index.tsx` around lines 199 - 203, The
single-row delete call using deleteMetrics([record.id]) currently only handles
success; add error handling so failures show feedback and do not refresh. Wrap
the delete call in a proper .catch (or convert to async/await with try/catch)
around the promise returned by deleteMetrics in the same block where
message.success(...) and setRefreshFlag(_.uniqueId('refreshFlag_')) are used; on
error call message.error(...) with an appropriate translated message (use
t('common:...') or include err.message) and avoid calling setRefreshFlag when
the delete fails. Ensure you reference deleteMetrics, message.success,
message.error, setRefreshFlag and _.uniqueId in the fix.
- Add Tags component with two-line overflow layout and ResizeObserver - Use Tags in the event count column with triggered/normal status display - Add i18n entries for status text and popover title across all locales
… in hosts list Move Tags from alertRules scope to components/TableTags for cross-page reuse; replace TableTags usage in hosts list with the unified Tags component.
…y column - Refactor Tags component to support generic typed data via getKey/getLabel - Support per-item bgColor/fontColor/icon via function props - Add maxWidth/borderRadius props for layout control - Extract calcLayout and add comprehensive test suite - Move alert rule category icon to datasource column - Add severity column with color-coded per-level tags - Merge nickname column into username column - Add click-to-open notification rules with not-found warning
- Remove scroll={{ x: 'max-content' }} from all table components to
simplify layout behavior
- Replace TableTags with the new Tags component using outline style
and consistent maxWidth
- Add null-safety to Tags component (accept null data, early return)
- Split update_at into two-row layout (date + time) across all tables
- Combine update_by/update_by_nickname and create_by/create_by_nickname
into single columns with stacked display
- Inline business group name into metric name column in recordingRules
…-0517 # Conflicts: # scripts/generate_antd_dark_less.js # scripts/generate_antd_gold_less.js # src/locales/common/locale/en_US.ts # src/locales/common/locale/ja_JP.ts # src/locales/common/locale/ru_RU.ts # src/locales/common/locale/zh_CN.ts # src/locales/common/locale/zh_HK.ts # src/pages/warning/shield/index.tsx # src/pages/warning/subscribe/ListNG.tsx # src/theme/antd.light-gold.less # src/theme/default.less
…-0517 # Conflicts: # src/pages/eventPipeline/pages/List/index.tsx
This reverts commit f4dd39e.
- Collapse action columns into 3-dot TableActionDropdown in Contacts, contacts list, notification channels/contacts, task result - Fix Rules-of-Hooks violation in shared TableTags: move empty-data guard below all hooks Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…kebab 把高频/特色行操作从三点菜单放出为行内图标（icon+tooltip，置于三点左侧），并从菜单中移除不重复。 新增共享 TableActionIconButton + TableActionCell（含 style.less 行内图标样式）。 放 1 个图标 + 三点留 CRUD：技能资源文件（查看）、事件管道（执行记录）、自愈任务（详情）、自愈脚本（立即执行）、ES 索引模式（配置）。 注：事件管道「执行记录」、自愈脚本「立即执行」原为路由 Link，放成图标按钮后改用 history.push（跳转一致，失去 cmd+点击开新标签）。待议表保持收起。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
feat(table): surface frequent row actions as inline icons beside the …
Collaborator
Author
|
改为从 main 重新设计实现（分支 feat-table-design-0601：EnhancedTable 薄透传 + 声明式行操作 + date/user/tags 列助手）。原分支历史经多轮反复已较乱，此 PR 关闭，新 PR 另提。 |
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
2 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.
Summary
Test
Summary by CodeRabbit
New Features
UI/UX Improvements
Refactor