-
Notifications
You must be signed in to change notification settings - Fork 369
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
An exception was thrown by the bridge (from user's code) #469
Comments
Could you provide an example to repro this? |
Actually, I feel this is the desired behavior. If client throws without catching we close the slave as we don't know whats wrong. What is the actual problem you're having with this? |
Well, I believe the client (the end-user, browser) should receive what Symfony sent to it, Error 500 with headers, but not just 502 error from Nginx over php-pm. In the case of development mode and with debug=0, I need every time to reach php-pm logs instead of just getting what's wrong from the answer. Maybe php-pm can just retranslate any exception to the user? Another example I got suddenly (updated configuration) and it persisted before I removed the cache completely. It's Symfony (level) error. I cannot catch this. Maybe in production mode, this behavior is okay cause some external logger usually used and deployment scaled to many pods.
|
I remember this issue and its a tricky one, because, on the one hand, the behavior is correct (the slave should definitely not handle any more requests after the exception) but on the other hand, this behavior prevents us from sending a proper response to the browser (as the slave closes abruptly). I'm not sure if there is a way to have the slave return a response and then close without serving any more requests? I don't think this can be implemented on the bridge level alone, because afaik if the bridge returns a response it cannot control whether the slave will close or not. @andig any ideas? |
To summarize the discussion sofar: currently- when client throws- PPM returns:
Instead, it should return (an exception response as Symfony does?) with HTTP 500. |
If you ask me, ideally the behavior should be that if debug is true it would return the exception message and the stack trace to the browser, while if its false it would show a generic message like "An error occurred" and just log the actual exception as usual. |
Hello,
I got:
Instead of normal Symfony's error-500, that's caused by my error in the application. But just I don't know why php-pm died on that, cause that error was on the application/payload level. Here the log:
Environment:
The text was updated successfully, but these errors were encountered: