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

Skip to content

Events profiler and logs get confused when an exception is thrown in one of listeners #24275

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

Closed
Xymanek opened this issue Sep 21, 2017 · 1 comment

Comments

@Xymanek
Copy link

Xymanek commented Sep 21, 2017

Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.3.8

Events panel

No exception behaviour:
screenshot_1

Exception in marked listener:
screenshot_2

Note that in case of exception the previous listeners successfully run and then all kernel.controller listeners were called again (without any exceptions). Sub-request profiler shows exactly the same events and logs view.

Logs panel

The thrown exception was NotFoundHttpException and this is the log view (very long): https://user-images.githubusercontent.com/2865341/30692725-73b966be-9ed5-11e7-8e7d-9a17de034981.png

Notice how it says

Notified event "kernel.controller" to listener "Symfony\Component\EventDispatcher\Debug\WrappedListener::__invoke"

Order of events is weird too:

request -> controller -> response -> finish_request -> exception -> response -> finish_request

While in reality (using xDebug):

request -> security.authentication.success -> controller -> exception -> request -> controller -> controller_arguments -> response -> finish_request -> response -> finish_request -> terminate

@nicolas-grekas
Copy link
Member

@ro0NL would you like to give this one a try, taking inspiration from #23659?

fabpot added a commit that referenced this issue Nov 26, 2018
This PR was merged into the 3.4 branch.

Discussion
----------

[EventDispatcher] Unwrap wrapped listeners internally

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | partially #24275
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

I believe what happens is we re-register the listeners on the wrapped dispatcher, so in case of sub request we get those and wrap it again. The profiler seems to confirm this in case of an exception (default 404 here) and thus creates a sub-request.

## Before: (main request)

No exception: (OK)

![image](https://user-images.githubusercontent.com/1047696/48968597-295ec180-eff2-11e8-982c-756e9019e107.png)

Exception: (KO)

![image](https://user-images.githubusercontent.com/1047696/48968612-4abfad80-eff2-11e8-8556-37bfbd51bc3b.png)

## After (main request):

No exception: same

Exception: (OK)

![image](https://user-images.githubusercontent.com/1047696/48968636-9f632880-eff2-11e8-983e-b4099133600b.png)

I haven't furhter investigated if we should split events per request as done in #23659 for logs. It seems somewhere we deduplicate events.. so im not sure the profiler actually shows correct data.

Commits
-------

448e2e2 [EventDispatcher] Unwrap wrapped listeners internally
@fabpot fabpot closed this as completed Apr 2, 2019
fabpot added a commit that referenced this issue Apr 2, 2019
This PR was squashed before being merged into the 4.3-dev branch (closes #29312).

Discussion
----------

[EventDispatcher] Split events across requests

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #24275
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

Split events per request, as currently a profiled sub-request includes all events. Follows same approach how logs are split in #23659.

Commits
-------

c3477ba [EventDispatcher] Split events across requests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants