-
Notifications
You must be signed in to change notification settings - Fork 661
fix(metrics): reject usize::MAX as cardinality limit #3506
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -259,6 +259,11 @@ impl StreamBuilder { | |
| if limit == 0 { | ||
| return Err("Cardinality limit must be greater than 0".into()); | ||
| } | ||
| // Reject usize::MAX because the SDK's internal HashMap capacity | ||
| // is sized as `1 + cardinality_limit`, which would overflow. | ||
| if limit == usize::MAX { | ||
| return Err("Cardinality limit must be less than usize::MAX".into()); | ||
| } | ||
| } | ||
|
|
||
| // Validate bucket boundaries if using ExplicitBucketHistogram | ||
|
|
@@ -544,8 +549,24 @@ mod tests { | |
| "Expected cardinality limit validation error message" | ||
| ); | ||
|
|
||
| // Test usize::MAX (invalid — would overflow internal `1 + limit` capacity) | ||
| let builder = StreamBuilder::new() | ||
| .with_name("valid_name") | ||
| .with_cardinality_limit(usize::MAX); | ||
|
|
||
| let result = builder.build(); | ||
| assert!( | ||
| result.is_err(), | ||
| "Expected error for usize::MAX cardinality limit" | ||
| ); | ||
| assert_eq!( | ||
| result.err().unwrap().to_string(), | ||
| "Cardinality limit must be less than usize::MAX", | ||
| "Expected cardinality limit usize::MAX error message" | ||
| ); | ||
|
|
||
| // Test valid cardinality limits | ||
| let valid_limits = vec![1, 10, 100, 1000]; | ||
| let valid_limits = vec![1, 10, 100, 1000, usize::MAX - 1]; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Marking Should we either tighten the validation to a sane upper bound, or decouple the initial HashMap capacity from the configured cardinality limit so a high limit doesn't force a huge upfront allocation?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Exactly this. The fix that was reverted was not centered around the integer overflow. The fix was to avoid the huge (and wasteful) up-front allocation. By reverting my PR, a very real bug is being re-introduced.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The discussion about disabling cardinality limit (modifying upfront allocation logic) is being tracked in this #3507. It would be worked upon after the 0.32 release. |
||
| for limit in valid_limits { | ||
| let builder = StreamBuilder::new() | ||
| .with_name("valid_name") | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add this PR's link.