KusionStack / karpor / 38127088878
65%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 68
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 63.83% (+0.03%) from 63.801%
38127088878

push

github

web-flow 
fix(ui): stop error toast spam and stuck spinner for stale pod rows (#854)

## What type of PR is this?

/kind bug

## What this PR does / why we need it:

On the topology view, expanding a ReplicaSet's Pod table renders one
`PodStatusCell` per row, each polling `/rest-api/v1/insight/summary` for
that pod's live status. When a pod is still present in the search index
but has already been deleted from the live cluster (a
maintainer-acknowledged, expected transient inconsistency between the
search index and the cluster, per the discussion on the linked issue),
that call returns `{success:false, message: "pods \"X\" not found"}`
over HTTP 200.

Today every such row triggers a disruptive global error toast, and the
row's status cell is left spinning forever, because the shared
`useAxios` hook's `handleResponse` never updates its `response` state on
a failed `/rest-api` call -- it only fires the notification and returns,
so callers can't distinguish "still loading" from "request finished but
failed".

This PR adds an opt-in `silentError` option to `useAxios` (default
`false`, so every other existing call site is unaffected).
`usePodStatus` passes `silentError: true` and now distinguishes "no
response yet" (stays "Loading") from "response arrived but failed"
(resolves to "Unknown", a status value already recognized by
`PodStatusCell`'s existing color mapping).

This does not address the underlying search-index/cluster staleness
itself (a separate, harder problem the maintainer is still investigating
on the issue thread); it only makes the UI degrade gracefully -- no
error-toast spam, no stuck spinner -- when that staleness is
encountered.

**Validation:** This sandbox's disk was exhausted at the OS/container
level (confirmed via `df -h`, unrelated to this repo), so `npm
install`/`npm run lint`/`npm run build` could not be run here. Instead,
a standalone dependency-free `node -e` script mirroring the exact branch
logic added to both `handleResponse` and `use... (continued)

4396 of 6887 relevant lines covered (63.83%)

0.7 hits per line

Jobs
ID Job ID Ran Files Coverage
1 38127088878.1 68
63.83
GitHub Action Run
Source Files on build 38127088878