Skip to content

analyze: --max-events caps usable events, not leading raw ops #19

Description

@echemythia

Problem

The CLI help and docs say --max-events analyzes at most N leading ops, but the streaming loader stops after N usable NormEvent entries. Lines skipped by the analyzer, including failed GETs, 304s, partial records, missing timestamps and non-cacheable operations, do not count toward the cap.

I reproduced this with failed s3tap operation records followed by successful GETs and --max-events 2. analyze skipped the earlier failures and reported on the later two successful GETs.

Impact

A user asking for a leading time slice can get a later slice biased toward cacheable demand reads. This is mostly a contract and sampling semantics issue, but it can change the workload being modeled on skip-heavy captures.

Expected direction

Choose and document one semantic:

  • cap raw input records or raw s3tap operation records before adaptation, matching the current wording, or
  • keep capping usable events but rename the docs/help to say usable cache events and disclose skipped-before-cap behavior.

Add an e2e or unit test covering skip-heavy input.

Relevant paths

  • crates/s3tap-cli/src/main.rs::AnalyzeArgs
  • crates/s3tap-cli/src/main.rs::analyze_cmd
  • crates/s3tap-cli/src/main.rs::stream_bounded
  • crates/s3tap-advisor/src/analyze.rs::load_trace_counted

Metadata

Metadata

Assignees

No one assigned

    Labels

    analyzeDeep caching and prefetch analysis commandcliCLI UX, flags, exit codes, setup and terminal outputdocumentationImprovements or additions to documentationtestingTesting, validation or coverage gap

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions