Skip to content

ROX-33540: adds rate limiting#499

Open
Stringy wants to merge 2 commits intomainfrom
giles/ROX-33540-rate-limiting
Open

ROX-33540: adds rate limiting#499
Stringy wants to merge 2 commits intomainfrom
giles/ROX-33540-rate-limiting

Conversation

@Stringy
Copy link
Copy Markdown
Contributor

@Stringy Stringy commented Apr 13, 2026

Description

  • RateLimiter component added between HostScanner and Output
  • Metrics added to monitor dropped events
  • Tests added to confirm rate limiting behavior

Checklist

  • Investigated and inspected CI test results
  • Updated documentation accordingly

Automated testing

  • Added unit tests
  • Added integration tests
  • Added regression tests

If any of these don't apply, please comment below.

Testing Performed

Integration tests cover the most common cases - unlimited rate limiting (send everything) and limited rate, confirming that the limit is restricting the event flow.

- RateLimiter component added between HostScanner and Output
- Metrics added to monitor dropped events
- Tests added to confirm rate limiting behavior
@Stringy Stringy marked this pull request as ready for review April 13, 2026 12:30
@Stringy Stringy requested review from a team and rhacs-bot as code owners April 13, 2026 12:30
Copy link
Copy Markdown
Contributor

@ovalenti ovalenti left a comment

Choose a reason for hiding this comment

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

Thanks for the swift work on this one 👍

/// means unlimited (no throttling).
///
/// Default value is 0 (unlimited)
#[arg(long, short = 't', env = "FACT_RATE_LIMIT")]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there a particular reason to have an explicit short parameter name ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

ahh this is left over from my first attempt. I'll remove the explicit name and let clap figure it out.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

having said that, an automatic name would clash with ringbuf_size. Perhaps -l (meaning limit)?

metrics: EventCounter,
) -> anyhow::Result<Self> {
let limiter = Self::build_limiter(*rate_config.borrow());
let (tx, _) = broadcast::channel(100);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I am curious to know whether the channel starts blocking when it is full, or if it drops events ?

Is this what triggers the RecvError::Lagged(..) type of messages ?

If we can loose messages this way, maybe we should count those occurrences ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good point. Back pressure will cause events to drop. I'll add a metric for this.

fact/Cargo.toml Outdated
env_logger = { workspace = true }
glob = { workspace = true }
globset = { workspace = true }
governor = { workspace = true}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
governor = { workspace = true}
governor = { workspace = true }

Comment on lines +72 to +73
assert total_accounted >= num_files - 5, \
f'Too many unaccounted events: received={received_count}, dropped={dropped_count}, created={num_files}'
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't understand the goal of this assertion. Ideally, total_accounted should be as close as possible to num_files, or I am missing something.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'm probably being a bit too defensive here. The idea was to have a timing tolerance to avoid flakes but perhaps a precise assertion is clearer

@Stringy Stringy requested a review from ovalenti April 13, 2026 14:51
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.

2 participants