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

Health check mock timeouts #39

Open
ScottFreeCode opened this issue Oct 18, 2021 · 3 comments
Open

Health check mock timeouts #39

ScottFreeCode opened this issue Oct 18, 2021 · 3 comments
Labels
enhancement New feature or request
Milestone

Comments

@ScottFreeCode
Copy link
Contributor

Depending on the developer machine (and not the project), sometimes mocks can take longer than their health check time to finish spinning up. It would be helpful to check for a user-level or system-level configuration that can override the health check timing for the mocks, either all mocks or specific ones.

@shanejansen
Copy link
Owner

This is an interesting problem. I wonder if the health check could be enhanced altogether to avoid this issue. Instead of depending on time, wait for some "healthy" keyword in the mock's startup output.

The default health-check timeout could probably just be increased a considerable amount in the meantime...

@shanejansen shanejansen added the enhancement New feature or request label Nov 2, 2021
@shanejansen shanejansen added this to the 1.4.1 milestone Nov 2, 2021
@ScottFreeCode
Copy link
Contributor Author

A similar problem can apply to the services if a developer's machine is significantly slower than some teammates' machines or CI. They could check into the repo a num retries that is enough for the slowest machine. Or they can manually tweak it without checking it in.

But I wonder if some kind of mechanism could be introduced whereby a slower machine has global configuration that increases the Touchstone time allowed for startup of mocks or services on top of or proportional to the configured time. Then we solve both the built-in mocks problem and the services problem without having to tweak the project's normal timing for the slowest developer machine.

(Ideally do it by increasing number of tries rather than time between retries? I recommend that to team members so they avoid waiting extra seconds after it becomes healthy before the next retry detects said healthy state.)

@ScottFreeCode
Copy link
Contributor Author

Note that something of this nature should not be necessary for processing period or other timing controlled by tests, as those could code machine settings through environment variables, choose the formula by which the time is derived (e.g. maybe a constant baseline is added to a multiplied time rather than using only a multiplier), etc. Letting the tests code their timing is more flexible and, I think, already supported.

This is only about container startup where we currently can't override the mock timeout or set a machine-dependent factor on the service timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants