feat: Add seqcli events delete command

[mloskot]

The events delete command is modelled after the seqcli search and accepts date range as well as filter expressions.

The events delete command is covered with e2e tests.

The idea of adding delete command came up in this thread:

• How to manually trigger retention policy? seq-tickets#2529

seqcli delete or seqcli events delete

Since there search and ingest are not sub-commands of seqcli events, I decided to follow the convention and add seqcli delete instead of seqcli events delete.

I eventually refactored the command into seqcli events delete, see discussion in #445 (review)

Testing

$  dotnet run -- Delete.* --docker-server --verbose
dotnet run -- Delete.* --docker-server --verbose
Using launch settings from /home/mloskot/workshop/seq/seqcli/test/SeqCli.EndToEnd/Properties/launchSettings.json...
TESTING /home/mloskot/workshop/seq/seqcli/src/SeqCli/bin/Debug/net10.0/seqcli.dll
RUNNING EventsDeleteWithDateRangeNoneTestCase             
RUNNING EventsDeleteTestCase                              
RUNNING EventsDeleteWithDateRangeSomeTestCase             
RUNNING EventsDeleteWithFilterTestCase                    
PASS
RUNNING EventsDeleteWithDateRangeAllTestCase              
PASS
PASS
PASS
PASS
Done; 5 total, 5 passed, 0 failed, 0 skipped.

I have also tested seqcli events delete against live server running Seq 2025.2.15571.

Examples

$ seqcli events delete -f "app='myservice'"
$ seqcli events delete --start=2026-02-11T23:00:00.01Z --end=2026-02-12T23:59:59Z
$ seqcli events delete --start=2026-02-11T23:00:00.01Z --end=2026-02-12T23:59:59Z --filter="app='myservice'"

[nblumhardt]

Looks great, thanks, just some minor comments.

I think this should still go under events delete; although it would be the odd one out right now, it's a fringe scenario (retention policies are preferred and perform much better), while the top-level commands are generally for day-to-day scenarios. It's also possible we'll end up with a metrics delete in the future.

(If I could go back in time I'd probably not put any commands at the root level, but that ship sailed long ago 😅 .)

[mloskot]

@nblumhardt

(If I could go back in time I'd probably not put any commands at the root level, but that ship sailed long ago 😅 .)

I kind of sensed that. Still, I wanted to remain explicit with my decision process and provoke exactly the discussion we are having here 😅

Looks great, thanks, just some minor comments.
I think this should still go under events delete;

Yup, that's a good idea indeed and regarding your other feedback, good one, thanks. I will refactor the PR tomorrow (I'm in CET).

[mloskot]

Hi @nblumhardt,
I think I've applied all the suggestions.

I may be lacking some .NET fu here, but I'm not sure why the Delete.* pattern can find tests, whereas EventsDelete.* does not:

$ dotnet run -- EventsDelete.* --docker-server --verbose
Using launch settings from /home/mloskot/workshop/seq/seqcli/test/SeqCli.EndToEnd/Properties/launchSettings.json...
TESTING /home/mloskot/workshop/seq/seqcli/src/SeqCli/bin/Debug/net10.0/seqcli.dll
Done; 0 total, 0 passed, 0 failed, 0 skipped.