Skip to content

fix/duration-filters - #2127

Open
alanpeixinho wants to merge 2 commits into
kernelci:mainfrom
profusion:fix/duration-filters-428-2126
Open

alanpeixinho wants to merge 2 commits into
kernelci:mainfrom
profusion:fix/duration-filters-428-2126

Conversation

@alanpeixinho

Copy link
Copy Markdown
Contributor

What it is

Fixes duration filter handling in the dashboard and API:

  • Duration filters showing 0 filter card #428: 0 is not treated as an active duration filter (no chip, not persisted, not sent). Duration inputs show 0 correctly (?? instead of ||). Clearing a duration field removes it from filter state.
  • wrong param parse on build duration #2126: Non-zero duration filters work from URL state and query params: minified URL keys parse as numbers, Zod coerces duration values safely, API mapping only sends active durations, and the backend no
    longer truncates multi-digit values (e.g. 3600 → 3) when filters come from the query string.

Closes #428
Closes #2126

How to test

  1. Open a tree view with duration filters (build / boot / test).
  2. Set min or max to 0 → no duration chip; other filters unchanged.
  3. Set a non-zero duration (e.g. build min 120) → chip appears; results respect the filter.
  4. Reload or share the URL with duration in df|… → chip and filter still apply.
  5. (API) Request with filter_duration_[lte]=3600 → results match 3600, not 3.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these tests does not cover the POST path used by Tree Details and Hardware Details, right?

worth adding a process_body=True

Comment on lines +213 to +217
if (value === '') {
delete next[field];
} else {
next[field] = Number.parseInt(value, 10);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this guards '' but other values can also become NaN.

Even if the input is of type number, I think it's worth using Number.isFinite to validate the parsed value.

Closes kernelci#428

Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>
Closes kernelci#2126

Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>
@alanpeixinho
alanpeixinho force-pushed the fix/duration-filters-428-2126 branch from d5b4e70 to f232d48 Compare September 23, 2026 12:58
});
});

describe('duration filter issue #428', () => {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd not reference github issues in test names. Give it a description that we can understand without leaving the editor and put a link to the issue as a comment.

// ensures https://github.com/kernelci/dashboard/issues/428
describe('...', () => {});

Comment on lines +163 to +169
export const getActiveDurationFilter = (value: unknown): number | undefined => {
if (value === undefined || value === null || value === '') {
return undefined;
}
const n = typeof value === 'number' ? value : Number(value);
return Number.isFinite(n) && n !== 0 ? n : undefined;
};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pondering if this is too permissive. Since value is unknown we can get anything here.

Maybe we should do something like:

export const getActiveDurationFilter = (
  value: unknown,
): number | undefined => {
  if (typeof value !== 'string' && typeof value !== 'number') {
    return undefined;
  }

  if (typeof value === 'string' && value.trim() === '') {
    return undefined;
  }

  const n = Number(value);

  return Number.isFinite(n) && n !== 0 ? n : undefined;
};

OR restricting the type of value param

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

wrong param parse on build duration Duration filters showing 0 filter card

2 participants