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.
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.