Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

tui/audit: delete-all and export-all silently ignore the active filter and a 1000-row cap

Closed
  • Is something wrong?
#145 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
57/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
cli, security

Research direction

Start with tui/audit/audit_keys.go at the delete-all and export-all actions, then read audit_keys_test.go around line 449 and how the audit view stores its active filter. Reproduce both cases with a filtered subset and more than 1000 matching rows. Done means delete-all respects the displayed subset, export-all includes all matches or clearly warns about a cap, and a test covers filtered deletion.

Written by the indexing model from the issue text.

Description

bug help wanted

Problem

Three related issues in packages/tui/audit/audit_keys.go:

  1. :205 — the "delete all" action operates on the full unfiltered log set rather than respecting whatever filter the user currently has applied in the view, so a user who filtered the view down to a subset and triggers "delete all" ends up deleting entries outside that filtered view too.
  2. :233 — "export all" silently caps the exported set at 1000 rows with no indication to the user that the export was truncated, so a log with more than 1000 matching entries produces an incomplete export the user may not realize is incomplete.
  3. audit_keys_test.go:449 — there is no test covering the filtered "delete all" case, so this bundling/scoping bug would not be caught by the test suite.

Impact

A user applying a filter before "delete all" can lose entries they did not intend to delete, since the action silently operates on the full log rather than the filtered subset shown on screen. A user exporting more than 1000 matching entries gets a silently truncated export file and may believe it contains the complete filtered dataset when it does not.

Repro

  1. Apply a filter in the audit view (e.g. by agent or by DLP match) that narrows the displayed entries to a subset, then trigger "delete all"; observe entries outside the filtered subset are also deleted.
  2. Apply a filter (or none) that matches more than 1000 entries, trigger "export all", and observe the resulting export file contains only 1000 rows with no warning that more entries existed.

Suggested fix

Make "delete all" operate only on the currently filtered/displayed entry set, not the full underlying log, when a filter is active. Remove (or clearly surface) the 1000-row export cap: either export the full filtered set regardless of size, or if a cap remains necessary for resource reasons, show an explicit warning/prompt when the matching set exceeds it. Add a test covering "delete all" with an active filter to lock in the corrected scoping behavior.

Dominant language
Go
Stars
157
Forks
19
Avg merge
4h 32m
Merged PRs (30d)
96

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 solongate/agent-security

All issues in solongate/agent-security

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.