fix(dashboard): honour DASHBOARD_AUTO_REFRESH_INTERVALS in the refresh dropdown - #44982

The flagged issue is correct. Using Number(value) on null or an empty string results in 0, which can incorrectly cause the UI to treat malformed configuration as a valid "Don't refresh" option.

To resolve this, you should validate the input more strictly before converting it to a number. The current PR already implements a robust fix in getRefreshFrequencyOptions by checking Number.isFinite(seconds) and ensuring the label is a non-empty string.

If you are referring to the handleRadioChange function specifically, you can improve the conversion there as well:

  const handleRadioChange = (event: RadioChangeEvent) => {
    const rawValue = event.target.value;
    const selectedValue = rawValue === '' || rawValue === null ? NaN : Number(rawValue);
    
    if (Number.isNaN(selectedValue)) {
      return;
    }
    // ... rest of the logic

I have checked the PR and there are no other pending review comments in the provided context. Would you like me to review any other parts of the PR?

superset-frontend/src/dashboard/components/RefreshFrequency/RefreshFrequencySelect.tsx

const handleRadioChange = (event: RadioChangeEvent) => {
    const rawValue = event.target.value;
    const selectedValue = rawValue === '' || rawValue === null ? NaN : Number(rawValue);
    
    if (Number.isNaN(selectedValue)) {
      return;
    }
    // ... rest of the logic

Thanks for the review — taking the first two, pushing a follow-up commit.

Duplicate option values — fixed: getRefreshFrequencyOptions now tracks collected intervals in a Set and skips an entry whose seconds were already seen, so a deployment repeating [60, "1 minute"] cannot produce duplicate React keys or two simultaneously-checked radios. The first occurrence wins, and '600' (string spelling the same interval) is treated as the same value rather than a new one. Covered by keeps the first of two entries sharing an interval.

Conflicting presets naming — fixed: the local inside getRefreshFrequencyOptions is now baseOptions; presets remains the component-level name for the list with Custom filtered out, which is the only place isPresetValue consumes.

On the coercion point, the loose conversion was a real hole and the follow-up closes it: Number(null), Number('') and Number([]) are all 0, and 0 is the legitimate "Don't refresh" interval, so those values used to pass validation as a real option. The value is now only converted when it is a number or a non-blank string; anything else becomes NaN and the entry is dropped. Pinned by rejects values that coerce to a real interval.

Docstrings on new tests — not taking this one. BITO.md is not in the repository, and no test function in this tree carries a docstring (checked RefreshIntervalModal.test.tsx, Header/HeadlessAutoRefresh.test.tsx and the sibling suites under src/dashboard/components): the file-level ASF header is the convention. Adding per-test prose only to this PR would make it inconsistent with everything around it. Happy to add them if the maintainers actually want that convention introduced.

CodeAnt PR Risk: Low Risk

• The PR appears safe to merge; configured intervals are validated, deduplicated, and covered by focused tests.
• Tests also cover bootstrapped configuration, saved values missing from the configured list, and Custom selections that collide with presets.

Assessed commit: 7090b0ebff84

✅ Deploy Preview for superset-docs-preview ready!

Name	Link
🔨 Latest commit	33dfe7d
🔍 Latest deploy log	https://app.netlify.com/projects/superset-docs-preview/deploys/6acb44951134a4000844eabd
😎 Deploy Preview	https://deploy-preview-44982--superset-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Good catch — fixed in 1f6ec28: the selector now falls back to the bootstrapped state.common.conf.DASHBOARD_AUTO_REFRESH_INTERVALS when dashboardInfo has no config, so the select renders the configured list on the Dashboard List / Home paths too (PropertiesModal mounts it from DashboardList/index.tsx with only the bootstrapped store). Added two regression tests: one rendering with only state.common hydrated, one asserting the hydrated dashboard config still wins when both exist. Both fail without the fallback.

Codecov Report

❌ Patch coverage is 98.30508% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 82.90%. Comparing base (e229ea4) to head (7090b0e).

@@           Coverage Diff           @@
##           master   #44982   +/-   ##
=======================================
  Coverage   82.90%   82.90%           
=======================================
  Files        3018     3018           
  Lines      193288   193334   +46     
  Branches    45018    45052   +34     
=======================================
+ Hits       160236   160277   +41     
- Misses      30014    30019    +5     
  Partials     3038     3038           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.