Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[HttpKernel] Exception after kernel.terminate runs kernel.exception, kernel.response and kernel.finish_request listeners again #45205

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.

Sign up for GitHub

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

Jump to bottom
Closed
fancyweb opened this issue Jan 27, 2022 · 5 comments
Closed

[HttpKernel] Exception after kernel.terminate runs kernel.exception, kernel.response and kernel.finish_request listeners again #45205

fancyweb opened this issue Jan 27, 2022 · 5 comments
Labels
Bug HttpKernel Stalled Status: Needs Review

Comments

@fancyweb
Copy link
Contributor

Symfony version(s) affected

All

Description

If a kernel.terminate listener throws an exception, HttpKernel ends up dispatching kernel.exception again.

Then, if a kernel.exception listener sets a response, kernel.response is redispatched a second time while the response has already been sent (a lot of "useless" code is executed).

Finally, kernel.finish_request is always redispatched a second time.

How to reproduce

Throw an exception in a kernel.terminate listener.

Possible Solution

  1. I think dispatching kernel.exception again can make sense. But we should stop there.

  2. We can also stop before dispatching it.

Also if this is really a wrong behavior, the subject is probably sensible, I don't think we can treat it as real a bug fix, we would need to deprecate it first.

Additional Context

No response
@fancyweb fancyweb added the Bug label Jan 27, 2022
@fancyweb
Copy link
Contributor Author

Also if we go with option 1 it would be great to know whether we are in a pre or post terminate situation in ExceptionEvent. We could also have kernel.terminate_exception instead 🤷‍♂️

@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@carsonbot
Copy link

Friendly reminder that this issue exists. If I don't hear anything I'll close this.

@carsonbot
Copy link

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

@VincentLanglet
Copy link
Contributor

@carsonbot, this issue is still relevant.

Hi @fancyweb, I recently encounter an issue which I think seems related to your point.

In my TerminateListener an exception is thrown

  • with Symfony ErrorHandler/DebugHandlersListener a KernelEvents::EXCEPTION is thrown
  • this trigger the Symfony ErrorListener
  • this trigger the ErrorController
  • then the TwigErrorRenderer
  • and it try to render my custom TwigBundle/Exception/error.html.twig
  • which logs an exception because I use app.session.flashbag when the header are already sent

But like you said the extra response is useless.

I think indeed a kernel.terminate_exception should be sent instead of a classic kernel.exception or at least a way to differentiate those situation would help listeners sont handle differently the situation, because the Symfony ErrorController shouldn't be called for exception thrown in terminate events therefore

ErrorListener::onKernelException

should have a early return if the exception was thrown in a terminate event.

@VincentLanglet VincentLanglet mentioned this issue Oct 9, 2023
Closed
@fancyweb fancyweb mentioned this issue Oct 13, 2023
Merged
nicolas-grekas added a commit that referenced this issue Oct 18, 2023
@nicolas-grekas
feature #52047 [HttpFoundation][Runtime] Add $flush parameter to Resp…
923ecdb 
…onse::send() (fancyweb)

This PR was merged into the 6.4 branch.

Discussion
----------

[HttpFoundation][Runtime] Add $flush parameter to Response::send()

| Q             | A
| ------------- | ---
| Branch?       | 6.4
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | -
| License       | MIT

Inspired by #51912 and #45205 subjects

Adds optional argument `$flush` to `Response::send()`. If `$flush === false`, output buffers are not flushed/`*_finish_request()` and alike functions are not called.

We leverage that in the Runtime component by not flushing the output buffers when debug mode is on in order to see exceptions thrown in listeners listening on the `TerminateEvent` and also to feel a more "real" processing time of things happening on terminate.

Commits
-------

a3304cc [HttpFoundation] Add $flush parameter to Response::send()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug HttpKernel Stalled Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fancyweb @VincentLanglet @carsonbot