Skip to content
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

fix: fix slice init length #7731

Merged
merged 1 commit into from
Oct 8, 2024
Merged

Conversation

huochexizhan
Copy link
Contributor

The intention here should be to initialize a slice with a capacity of len(nameToString) rather than initializing the length of this slice.

@huochexizhan huochexizhan requested a review from a team as a code owner October 1, 2024 16:09
Copy link
Contributor

@aarongable aarongable left a comment

Choose a reason for hiding this comment

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

Thanks, another good catch!

It looks like we use limitNames in three places, all of which are being formatted into error strings: once in parseOverrideNameID, once in loadAndParseOverrideLimits, and once in loadAndParseDefaultLimits.

These functions are tested (here, here, and here), but those tests didn't catch this bug in the error message. I suspect that's because those tests don't assert very much about the error itself, just that the function returns an error at all, and that the error isn't a failure to load the test file.

Can I ask you to add some additional asserts to each of these tests, to ensure that the right error is being encountered in each case? These would look something like

	// Burst cannot be 0.
	_, err = loadAndParseOverrideLimits("testdata/busted_override_burst_0.yml")
	test.AssertError(t, err, "single override limit with burst=0")
-	test.Assert(t, !os.IsNotExist(err), "test file should exist")
+ 	test.AssertContains(t, err.String(), "invalid burst")

Thanks!

Signed-off-by: huochexizhan <huochexizhan@outlook.com>
@huochexizhan
Copy link
Contributor Author

Thanks, another good catch!

It looks like we use limitNames in three places, all of which are being formatted into error strings: once in parseOverrideNameID, once in loadAndParseOverrideLimits, and once in loadAndParseDefaultLimits.

These functions are tested (here, here, and here), but those tests didn't catch this bug in the error message. I suspect that's because those tests don't assert very much about the error itself, just that the function returns an error at all, and that the error isn't a failure to load the test file.

Can I ask you to add some additional asserts to each of these tests, to ensure that the right error is being encountered in each case? These would look something like

	// Burst cannot be 0.
	_, err = loadAndParseOverrideLimits("testdata/busted_override_burst_0.yml")
	test.AssertError(t, err, "single override limit with burst=0")
-	test.Assert(t, !os.IsNotExist(err), "test file should exist")
+ 	test.AssertContains(t, err.String(), "invalid burst")

Thanks!

Thanks. Modified. Please review again.

@aarongable aarongable requested review from a team and jsha and removed request for a team October 8, 2024 15:19
@beautifulentropy beautifulentropy merged commit a6dc97c into letsencrypt:main Oct 8, 2024
12 checks passed
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.

3 participants