[Bug] Overview and remove-runs "amount"/"limit" filters apply globally instead of per project, hiding or deleting whole projects

[MatheusAssisNeves]

Summary

Since #322 ("apply filter in overview"), the Overview page groups projects from filteredRuns — the fully filtered run list, including the global "amount" (last-N-runs) slice. That slice is applied across all runs from all projects combined, not per project. With multiple projects producing runs at different frequencies, a project whose runs are all older than the global last-N cutoff disappears entirely from the Overview (not just reduced — its whole section is missing), even though its data is still in the database. Default --quantity is 20, so this reproduces easily with 3+ projects of uneven run frequency.

The same "global instead of per-project" pattern exists in the retention/cleanup feature (--removeruns limit=N and the admin page's "remove by limit" field, _remove_by_limit() in database.py): it keeps the N newest runs globally unless the caller manually adds tag scoping (limit=10;tag=nightly). Used without scoping — the common case — "remove by limit" can silently wipe out the entire history of a low-frequency project while barely touching a high-frequency one.

Steps to reproduce (Overview)

1. Generate a dashboard with 2+ projects (distinguished by run name or project_* tag), where one project has far fewer/older runs than the others combined.
2. Open Overview with default settings (--quantity default = 20).
3. The low-frequency project's card section is missing from Overview entirely.

Expected vs actual

• Expected: Overview shows all projects, with the "amount" filter (if applied at all in this context) scoped per project — e.g. "last N runs of each project."
• Actual: the "amount" filter is applied once to the combined run list before grouping by project, so it can hide whole projects.

Known workaround and why it's not a real fix

Passing a large --quantity (e.g. --quantity 999999) works around the Overview symptom, since filter_amount() clamps to runs.length. But #amount is a single global input shared by Overview and the Dashboard/Tables tabs (filteredRuns/filteredSuites/filteredTests/filteredKeywords are all derived from it), so this also forces the Dashboard tab to render far more data by default and noticeably slows it down.

Suggested fix

• Overview: apply the "amount" limit per project when building projects_by_name/projects_by_tag in prepare_projects_grouped_data() (js/graph_creation/overview.js), instead of slicing the flat run list before grouping. Or exclude Overview grouping from the amount stage of the pipeline.
• _remove_by_limit() / admin & CLI retention: consider making project scoping automatic (e.g. default to per-project-tag/per-run-name grouping) rather than relying on the caller to manually pass matching tag= filters, or at minimum warn when an un-scoped limit is applied across multiple distinct projects.

References

• robotframework_dashboard/js/graph_creation/overview.js — prepare_projects_grouped_data(), create_project_overview()
• robotframework_dashboard/js/filter.js — filter_amount()
• robotframework_dashboard/arguments.py — --quantity (default 20)
• robotframework_dashboard/database.py — _remove_by_limit()
• Introduced/exposed by feat: apply filter in overview (#301) #322 (Overview grouping now consumes filteredRuns)

[timdegroot1996]

@MatheusAssisNeves this is a good finding, I hadn't thought about this before. I think having the amount filter active on the overview page at all is debatable. Your suggestion to have it per project does make sense as well but I think removing it alltogether would be better.

What do you think about this @HuntTheSun, since you originally started this feature?

[MatheusAssisNeves]

@timdegroot1996 Only concern I have with removing the amount cap entirely is both the visual clutter in each bar and probably the performance hit: every run card also spins up its own Chart.js donut instance, so a project with a long history (e.g. nightly runs over months) might means hundreds of live charts rendered on load.

[timdegroot1996]

@MatheusAssisNeves that makes sense. I think I tested it with like 400/500 donuts when it came out and even then it still performed fine, but keeping it might not be a bad idea. Im just afraid people wont find the setting...

[timdegroot1996]

Fixed in #350.

The amount filter and the retention limit are now both applied per project instead of on the combined run list. A project is a run's run name plus every project_ run tag — the same grouping the overview page uses — and the keys are prefixed internally so a run name can never collide with a run tag.

• Overview / dashboard (filter_amount): the runs are grouped per project and the last X of each group are kept, unioned. A run survives when it is one of the last X runs of at least one of its projects, so the total number of shown runs can be higher than X — and a project that runs less often is never pushed out by a busier one. @MatheusAssisNeves this keeps the donut cap you were worried about; the cap is just no longer shared across projects.
• Retention (-r limit=N, the admin "remove by limit" field, POST /remove-outputs): the N newest runs of every project are kept. The new keep set is a strict superset of the old one, so the change can never remove more than before. Combining it with tag= still narrows the candidates first, then the limit applies per project inside that scope.

The filter modal spells this out: the label is now "Amount per project" and its ⓘ popup explains the grouping and the "total can exceed X" consequence. The --quantity / -r limit= CLI help, the admin page, the server API examples and the docs were updated too.

Covered by new Python unit tests, JS unit tests and a robot acceptance test that asserts both project sections stay on the overview with amount=1.

[HuntTheSun]

Nice,
I will check it out later, thank you.
I was also thinking about doing this, but I did not want to change current behavior too much,
but this way was also the preferred behavior for me, I just didnt know if anybody else wanted it.
Its nice that I didnt have to solve that myself :)

Thanky you for your work :)

Im also thinking about maybe adding a setting for more minimal run charts, as to not require that much processing, I ran into that issue also.

[timdegroot1996]

Im also thinking about maybe adding a setting for more minimal run charts, as to not require that much processing, I ran into that issue also.

That's interesting to hear. How many donuts were you generating that it became an issue?

[HuntTheSun]

That's interesting to hear. How many donuts were you generating that it became an issue?

I think it was roughly 1.5-2k runs, that was before the Overview Filter option was added.
I don't quite remember my benchmarks, but I think the donut creation (or just the rendering, I dont recall) took up a significant time,
though I think the data prep for the run cards was the bigger performance hog.
I will have to check out an old commit and recheck to be sure though.

Its not a big priority for me now with the filtering in overview.
Before, my browser often asked me to close the tab because it thought it was stuck,
but JS single-thread iteration over my big dataset just took some time :)

[timdegroot1996]

@HuntTheSun interesting, I will try and test with 2k runs and see what that does performance wise just to be aware. But since I already implemented it per project I will leave that. Just satisfying my curiosity to see if the flow can be improved