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

helper: guard against negative inputs into random stagger #14497

Merged
merged 1 commit into from
Sep 8, 2022

Conversation

shoenig
Copy link
Member

@shoenig shoenig commented Sep 8, 2022

This PR modifies RandomStagger to protect against negative input
values. If the given interval is negative, the value returned will
be somewhere in the stratosphere. Instead, treat negative inputs
like zero, returning zero.

Before:

=== RUN   TestCluster_RandomStagger
    interface.go:24: 
        cluster_test.go:27: expected 2409629h13m43.082153551s <= 1s
--- FAIL: TestCluster_RandomStagger (0.00s)

This PR modifies RandomStagger to protect against negative input
values. If the given interval is negative, the value returned will
be somewhere in the stratosphere. Instead, treat negative inputs
like zero, returning zero.
Comment on lines +26 to +27
must.GreaterEq(t, result, 0)
must.LessEq(t, result, abs(tc.input))
Copy link
Member Author

Choose a reason for hiding this comment

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

Just now realizing I got these parameters backwards, shoenig/test#33

Copy link
Member

Choose a reason for hiding this comment

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

fwiw, having the parameters in the same "direction" as the operator feels more intuitive to me. ex. must.GreaterEq(t, a, b) reads like it should be checking a > b. Whereas for something like must.Eq there isn't an obvious expectation vs result in the way the parameters are named anyways.

@shoenig shoenig marked this pull request as ready for review September 8, 2022 14:34
@shoenig shoenig requested review from tgross and schmichael September 8, 2022 14:34
@shoenig shoenig added backport/1.2.x backport to 1.1.x release line backport/1.3.x backport to 1.3.x release line labels Sep 8, 2022
@shoenig shoenig added this to the 1.4.0 milestone Sep 8, 2022
Copy link
Member

@tgross tgross left a comment

Choose a reason for hiding this comment

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

LGTM

@github-actions
Copy link

github-actions bot commented Jan 7, 2023

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backport/1.2.x backport to 1.1.x release line backport/1.3.x backport to 1.3.x release line
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants