Skip to content

[HttpKernel] Provide status code in fragment handler exception #37537

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

Merged
merged 1 commit into from
Aug 10, 2020

Conversation

gonzalovilaseca
Copy link
Contributor

@gonzalovilaseca gonzalovilaseca commented Jul 9, 2020

Q A
Branch? 3.4
Bug fix? no
New feature? yes
Deprecations? no
Tickets
License MIT
Doc PR

We have a use case where it would be useful to retrieve the status code in an exception listener from the exception thrown by the fragment handler, current solution is to extract it from the exception string which is ugly.
With this change we can get the status code from the exception directly.

@nicolas-grekas nicolas-grekas changed the title [httpkernel] [fragment] Provide status code in fragment handler exception? [HttpKernel] Provide status code in fragment handler exception Jul 9, 2020
@nicolas-grekas
Copy link
Member

Can you please target master? That'd be a new feature.

@nicolas-grekas nicolas-grekas added this to the next milestone Jul 9, 2020
@gonzalovilaseca
Copy link
Contributor Author

sure!

@gonzalovilaseca gonzalovilaseca changed the base branch from 3.4 to master July 9, 2020 16:40
@gonzalovilaseca
Copy link
Contributor Author

gonzalovilaseca commented Jul 9, 2020

@nicolas-grekas done, and tests updated

@gonzalovilaseca gonzalovilaseca force-pushed the patch-1 branch 2 times, most recently from 425eccb to c966456 Compare July 9, 2020 18:24
@gonzalovilaseca
Copy link
Contributor Author

Build fails don't seem related to my changes

@gonzalovilaseca
Copy link
Contributor Author

@fabpot Updated with suggested changes

@stof
Copy link
Member

stof commented Jul 10, 2020

This does not only make the status code of the subrequest available in the exception. It also make it being used as the status code of the master request now (as the thrown exception is an HttpException) when this subrequest does not happen in Twig (I think Twig might be wrapping the HttpException into a Twig RuntimeError exception).

Maybe we should provide an HttpException only as the previous exception here.

@gonzalovilaseca
Copy link
Contributor Author

The second to last commit has @fabpot suggestion, last commit has @stof suggestion.
I'll update the test once the chosen option is clear :-)

@gonzalovilaseca
Copy link
Contributor Author

Polite reminder if someone can assess which suggestion to go for please?

@fabpot
Copy link
Member

fabpot commented Jul 31, 2020

I'm fine with @stof suggestion. Tests do not pass though.

@gonzalovilaseca gonzalovilaseca force-pushed the patch-1 branch 3 times, most recently from 824f6de to 6ae672a Compare August 3, 2020 14:52
@gonzalovilaseca
Copy link
Contributor Author

gonzalovilaseca commented Aug 7, 2020

PR Updated!
Failing tests seem to be not related to my PR it's some redis and http envelope errors, any ideas?

@fabpot
Copy link
Member

fabpot commented Aug 10, 2020

Thank you @gonzalovilaseca.

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.

5 participants