Expose Config.TestOnly configuration option for disabling staggered start
#414
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… start This one's a continuation of #385. Maintenance services have a staggered start feature that causes them to sleep for a random amount of jittered time on startup so they don't all try to work simultaneously. This is useful in production, but somewhat harmful in tests because it makes start and stop slower and thereby integration test cases slower. River has an internal flag that allows staggered start to be disabled in its own test suite, but external users of River have no way to access this functionality. Here, introduce `Config.TestOnly` that can be provided to client configuration in test suites regardless of whether the caller is internal or not. This differs slightly from #385 in that it provides only a boolean, with the idea being that if we find it useful to disable other features for tests in the future, a boolean keeps third party code for forwards compatible in that they get these disabled automatically. In case it does become important to distinguish between individual features at some later time, I figure we can add an additional `TestOnlyConfig` property that allows full configuration beyond defaults.
brandur
force-pushed
the
brandur-test-only
branch
from
9fe31da to
70a34c8
Compare
|
Damn, intermittency in |
bgentry
approved these changes
Jul 3, 2024
|
Awesome. NP! |
brandur
added a commit
that referenced
this pull request
Jul 9, 2024
I was looking into what was making the example tests so slow (some like the periodic job enqueuer one often take 3 seconds to run), and it turns out that the lion's share of it is from from service start up jitter. Example tests aren't in the main `river` package (they're in `river_test`) so they didn't previously have a way of interacting with the client in such a way as to disable stagger. Luckily, we do have a way now. Take advantage of the recently introduced `TestOnly` client property from #414 to make all the examples faster.
brandur
added a commit
that referenced
this pull request
Jul 9, 2024
I was looking into what was making the example tests so slow (some like the periodic job enqueuer one often take 3 seconds to run), and it turns out that the lion's share of it is from from service start up jitter. Example tests aren't in the main `river` package (they're in `river_test`) so they didn't previously have a way of interacting with the client in such a way as to disable stagger. Luckily, we do have a way now. Take advantage of the recently introduced `TestOnly` client property from #414 to make all the examples faster.
brandur
added a commit
that referenced
this pull request
Jul 9, 2024
I was looking into what was making the example tests so slow (some like the periodic job enqueuer one often take 3 seconds to run), and it turns out that the lion's share of it is from from service start up jitter. Example tests aren't in the main `river` package (they're in `river_test`) so they didn't previously have a way of interacting with the client in such a way as to disable stagger. Luckily, we do have a way now. Take advantage of the recently introduced `TestOnly` client property from #414 to make all the examples faster.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one's a continuation of #385. Maintenance services have a staggered
start feature that causes them to sleep for a random amount of jittered
time on startup so they don't all try to work simultaneously. This is
useful in production, but somewhat harmful in tests because it makes start
and stop slower and thereby integration test cases slower.
River has an internal flag that allows staggered start to be disabled in
its own test suite, but external users of River have no way to access this
functionality.
Here, introduce
Config.TestOnlythat can be provided to clientconfiguration in test suites regardless of whether the caller is internal
or not.
This differs slightly from #385 in that it provides only a boolean, with
the idea being that if we find it useful to disable other features for
tests in the future, a boolean keeps third party code for forwards
compatible in that they get these disabled automatically. In case it does
become important to distinguish between individual features at some later
time, I figure we can add an additional
TestOnlyConfigproperty thatallows full configuration beyond defaults.