-
Notifications
You must be signed in to change notification settings - Fork 132
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
POST to checkin.php always responses 200 despite any errors occuring. #266
Comments
Your guess is as good as mine 😉... This code has not been touched since 2012, long before I took over. It would probably make sense to return an HTTP 400 instead of relying on die() statements. I don't think there would be any problem doing that, but I don't know for sure (I only use the plugin with Github, which does not use this functionality). |
I see what you mean now. OK so the 400 errors would probably only apply to the cases already handled within checkin.php itself (where the die statements are). 500 is correct if it's a server error, but I'm not sure how to catch that within checkin.php; what you report is a standard MantisBT error page, we would probably need to have Mantis core throw an exception instead, to handle this properly. |
I am wondering if this is intentional behaviour to keep the "normal" caller happy or
a just make it work situation. For now the only "reliable" option left to catch errors is
to parse the actual response for any traces of errors or exceptions.
Background: I am running a post-commit hook (svn) to automatically checkin
commits to MantisBT with a POST to checkin.php. So there I need a safe way to
inform the client (exitcode, message, mail,...) if the checkin really happened.
The text was updated successfully, but these errors were encountered: