[Bug] COS UI Home > Chart: storage and ranking polls reuse the time window from page load on 3.2.0

Open Beginner friendly
  • Is something wrong?
#1,766 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@arasHi87 is already working on this.

Since Oct 9, 2026.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript
Domain
frontend

Research direction

Start with cube-cos-ui/packages/cube-frontend-web-app/src/pages/home/chart/_components/StoragePanels/useMetricsParams.ts, where the issue traces the fixed time window, and check how getTimeRangeParams() is used by the listed storage and ranking panels. Verify successive history/hosts and rank/hosts|vms requests have advancing stop values about 30 seconds apart; the charts should track the current time instead of going stale.

Written by the indexing model from the issue text.

Description

Description

The Home > Chart page polls the storage history and the Host/VM ranking endpoints every 30 s (CHART_PAGE_POLLING_INTERVAL), but every poll sends the same start/stop that was computed when the page first rendered. In a run that kept the page open about 10 minutes, every repeat was:

.../metrics/diskIops/history/hosts?start=2026-10-06T17:46:47+08:00&stop=2026-10-06T18:46:47+08:00
.../metrics/cpuUsage/rank/hosts?start=2026-10-06T17:46:47+08:00&stop=2026-10-06T18:46:47+08:00

As a result, a Chart page left open never shows new storage points or newer ranking values. After an hour the panels are fully stale, even though they appear to be "live".

Root cause (traced): cube-cos-ui/packages/cube-frontend-web-app/src/pages/home/chart/_components/StoragePanels/useMetricsParams.ts stores currentTime = useRef(dayjs()) once per mount, and getTimeRangeParams() derives start/stop from that ref. StorageBandwidthPanel, StorageIopsPanel, StorageLatencyPanel, HostRankingPanel and VmRankingPanel all use this hook.

How to Reproduce

  1. COS UI: Home, then Chart. Open DevTools > Network and filter metrics/.
  2. Leave the page open for 2 minutes or more.
  3. Compare the start/stop query parameters of successive .../history/hosts and .../rank/hosts|vms requests: they are identical on every poll.

Expected behavior

Each poll requests the last hour relative to the time of that poll (stop = now), so history lines and ranking values advance while the page stays open.

Screenshots (Optional)

None.

Additional Context (Optional)

  • Found by upgrade check #769 (story #772) on build CUBE_3.2.0_20261004-0551_cfc4886c in the 1cc test environment (regression run rt694-20261006).

  • Build: CUBE_3.2.0_20261004-0551_cfc4886c, the 1cc test node. Regression run rt694-20261006, task #769.

  • This is separate from #1618 (the storage series are empty because cube-cos-api reads a retired data source). Until #1618 is fixed only the ranking panels show this visibly; once it is fixed, this bug makes the storage charts freeze instead.

Device Information (Optional)

None.

QA Verification

# Command / steps Expected outcome
1 COS UI > Home > Chart, DevTools Network filter history/hosts, wait 90 s The three or more successive requests have stop values about 30 s apart
2 Same, filter rank/hosts stop advances on each poll
3 Leave the page open for 70 min with storage load running in a VM The Storage charts' right edge tracks the current time; no stale plateau
  • QA Status declared at Done — when this issue reaches Done, set the board's
    QA Status field to Not needed or Ready to QA. Never leave it empty on a Done
    ticket; In QA / Verified are QA's own transitions.

Output artifacts (Definition of Done)

Beyond code, docs, and config changes, completing this issue must also deliver:

  • Handbook knowledge update — land the durable, team-readable knowledge from this
    work into the bigstack-handbook cubecos kb (kb/cubecos/…) via
    /bigstack-core:save-to-handbook (Topic / Runbook / Known-issue / ADR as fits).
    Diagnosed or fixed a failure? Ship the scenario sidecar (<note>.scenario.yaml)
    beside the note.
Dominant language
Shell
Stars
161
Forks
19
Avg merge
1d 4h
Merged PRs (30d)
108

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bigstack-oss/cubecos

All issues in bigstack-oss/cubecos

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.