-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
probes do not treat 404 status as error #99
Comments
@klauss42 The probes are not traditional tests and they don't test for correctness in terms of what the response looks like. It's more about generating interactions with the applications and from that perspective it also benefits from going outside of the happy path :-) In a way, it's a bit like an input fuzzer... However, in some cases you do want a specific behavior and, in some cases, that specific response behavior is needed to get to certain parts of the application. Either way, you might find the The 4xx responses are a bit trickier when it comes to the default behavior. The most likely solution there will be to introduce some kind of 'expected response code' as one of the probe params. The probes will need to be scoped better too because, by default, the probes are executed against all available ports and if you have two ports (one for the main interface and another one for the admin interface, for example) one of them might return 404 (because the given endpoint isn't implemented there) and another might return 200 (e.g., it can be an admin interface only endpoint). Somewhat related... In some cases the response codes are different if the app is not fully initialized. Right now waiting for the app to fully initialize involves adding a wait time, which may not be always the same. The upcoming enhancements will make it possible to specify a 'readiness' endpoint probe that will simplify that setup. |
Thanks for your answer. Let me describe my problem: I am using mint to build a slim image of a quite huge machine learning model. Using the probes I am calling all relevant entrypoints of the image which works fine in most case. But sometimes startup of the container or initialization takes a bit longer and I expected that mint (and the build pipeline) would fail in these cases. But instead mint finishes the probes (with some probes on error) but continues building the slim image. I ended up with a slim image that did not work at runtime because mint removed stuff from the image that were important at runtime. Any ideas how to handle this? |
@klauss42 Very helpful context! I can quickly add |
If I configure probes I expected that mint fails if probes return an error. I would expect that both 40x or 50x status codes for probes should let mint stop processing and return an error.
E.g.
results in
mint reports 0 failures and continues building the image. In my case I want mint to fail, so that the build pipeline fails because something seems to be wrong with the target image resulting in the 404 (or 500) error.
Did I misunderstand or misuse something?
The text was updated successfully, but these errors were encountered: