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

HealthCheck sensitivity is not appropriate in all contexts #3367

Closed
epgui opened this issue Jun 7, 2022 · 1 comment · Fixed by #3376
Closed

HealthCheck sensitivity is not appropriate in all contexts #3367

epgui opened this issue Jun 7, 2022 · 1 comment · Fixed by #3376
Labels
enhancement it's not broken, but we want it to be better

Comments

@epgui
Copy link

epgui commented Jun 7, 2022

When generating relatively large json objects (or even arrays of such objects), one will frequently run into either a too_slow or a data_too_large HealthCheck failure.

While it is possible to disable these checks, doing so foregoes any benefit that the HealthCheck is supposed to bring.

In many situations, it would be preferable to have an option to tweak the sensitivity level of health checks. Maybe I know roughly how much data I want to generate, and I am okay with CI taking a few extra seconds to run my tests.

@Zac-HD
Copy link
Member

Zac-HD commented Jun 8, 2022

The goal of the HealthCheck system is just to ensure that you know if you're hitting these unusually large or slow cases - if that's intentional (which in your case it is), disabling them is perfectly fine. I don't think that making health checks configurable in general is valuable enough to justify the more complicated interface though.

We should probably reframe HealthCheck.too_slow in terms of the deadline setting, though 🤔

@Zac-HD Zac-HD added the enhancement it's not broken, but we want it to be better label Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement it's not broken, but we want it to be better
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants