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

Skip to content

[ErrorHandler] Render template with status code assigned to the exception #44456

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
wants to merge 2 commits into from

Conversation

aderiyenko
Copy link

Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Tickets Fix #44433
License MIT
Doc PR N/A
  • Injecting framework.exceptions config into Symfony\Component\ErrorHandler\ErrorRenderer\HtmlErrorRenderer
  • Passing the status code from the config into FlattenException::createFromThrowable()
  • Tests

Copy link
Member

@GromNaN GromNaN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for fixing this bug. Some small changes to make it ready.

@GromNaN GromNaN requested a review from lyrixx December 3, 2021 22:02
@derrabus derrabus modified the milestones: 6.1, 5.4 Dec 3, 2021
@carsonbot carsonbot changed the title Fixing #44433 [ErrorHandler] Fixing #44433 Dec 3, 2021
@GromNaN GromNaN changed the title [ErrorHandler] Fixing #44433 [ErrorHandler] Render template with status code affected to the exception Dec 3, 2021
@aderiyenko
Copy link
Author

@GromNaN Thanks for the review! I'm not sure how I can fix the tests in the pipeline. Where can I read more about Error: KO src/Symfony/Bundle/FrameworkBundle ?

Also, it throws some linting error about extra return in phpdoc, but this is not related to my change, so I put it back.

@GromNaN GromNaN changed the title [ErrorHandler] Render template with status code affected to the exception [ErrorHandler] Render template with status code assigned to the exception Dec 3, 2021
@GromNaN
Copy link
Member

GromNaN commented Dec 3, 2021

@GromNaN Thanks for the review! I'm not sure how I can fix the tests in the pipeline. Where can I read more about Error: KO src/Symfony/Bundle/FrameworkBundle ?

This error a not related to your changes. There is the same errors on the target branch (5.4).

Also, it throws some linting error about extra return in phpdoc, but this is not related to my change, so I put it back.

You can apply the patch from fabbot please.

@aderiyenko
Copy link
Author

done. I thought the pipeline should be all green in order to merge :) Anything else I can/should do in this branch?

@yceruto
Copy link
Member

yceruto commented Dec 4, 2021

For API exceptions it's the same problem.

@aderiyenko can you also update SerializerErrorRenderer? Thanks!

@aderiyenko
Copy link
Author

@yceruto sure, will look at it and try to do the same there and I saw your idea in the issue comments, so let me try to create another PR with another approach. I'll try to finish this one over the weekend and then will start with wrapping it into an http exception idea

@aderiyenko aderiyenko force-pushed the aderiyenko_44433 branch 2 times, most recently from 1939d4f to 480da75 Compare December 4, 2021 21:06
@aderiyenko
Copy link
Author

aderiyenko commented Dec 4, 2021

@yceruto I added the same functionality to SerializerErrorRenderer and realized there were no tests for the class, so added a couple, but they test only the status code/text, i.e. this PR parts. Not testing whether stack trace is returned/hidden in debug/prod mode

@aderiyenko aderiyenko force-pushed the aderiyenko_44433 branch 3 times, most recently from 26d9bb9 to ba34b94 Compare December 5, 2021 15:31
@aderiyenko
Copy link
Author

changed the wording of the additional config (exception type -> log_level/status code) parameter everywhere and also changed the hardcoded constants (status codes and texts) in tests to use the ones from HttpFoundation\Response

@aderiyenko
Copy link
Author

@GromNaN I see that my new tests pass in 7.4 pipeline, but fail in 8. See here: https://github.com/symfony/symfony/runs/4422885653?check_suite_focus=true . Problem is: I just tried to launch it inside a php:8.0.5-fpm-alpine container (with only xdebug3 installed) and it passes fine, so I can't recreate it locally. Is there any specific config in the pipeline that I can reproduce locally ?

@aderiyenko
Copy link
Author

Is my understanding correct that low- and high-deps pipelines install all components of certain versions, so the tests covering the new functionality in any PR will never work in those pipeline steps? Because these versions do not have the functionality being tested?

@yceruto
Copy link
Member

yceruto commented Dec 10, 2021

@aderiyenko you should update the affected composer.json accordingly to make it pass. For example, after these changes FrameworkBundle is no longer compatible with "symfony/error-handler": "^5.4|^6.0", so you have to limit it to ^6.1.

@GromNaN
Copy link
Member

GromNaN commented Dec 10, 2021

@yceruto this is a bugfix, I think we should not update the dependencies in that case.

@yceruto
Copy link
Member

yceruto commented Dec 10, 2021

You're right, I confused the branch this PR targeted. Initially, it was 6.1.

@wouterj
Copy link
Member

wouterj commented Dec 10, 2021

Iirc, in that case, require the upcoming minor version: ^5.4.2|^6.0.2

@aderiyenko
Copy link
Author

Thanks everyone! I just bumped the versions of error handler in FrameworkBundle's composer.json , but the same errors are still there. But I'm more interested if there are certain steps I can take locally to reproduce the problem?

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the PR, I really appreciate that you took the time to write and submit it.
Having reviewed the code, the added logic doesn't make sense to me. It feels like spreading a concern to places where it doesn't belong.
On a closer look, I think the implementation provided in #42244 is at fault and that it should be changed.
I gave it a try and submitted it at #44649.

Thanks again. I'm 👎 here as explained.

@aderiyenko
Copy link
Author

Sure, thanks @nicolas-grekas

@aderiyenko aderiyenko closed this Dec 15, 2021
nicolas-grekas added a commit that referenced this pull request Dec 16, 2021
… by exception works (nicolas-grekas)

This PR was merged into the 5.4 branch.

Discussion
----------

[HttpKernel] fix how configuring log-level and status-code by exception works

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #44433
| License       | MIT
| Doc PR        | -

This PR replaces #44456, and essentially fixes the way configuring log-level/status-code by exception works: instead of hacking them in the listener, the original exception should be wrapped in an `HttpExceptionInterface`, so that the rest of the code can seamlessly know about the configuration.

Commits
-------

6617be4 [HttpKernel] fix how configuring log-level and status-code by exception works
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[HttpKernel] Wrong template is rendered when configuring an exception status code
8 participants