This repository has been archived by the owner on Jan 29, 2020. It is now read-only.
Finalhandler production stacktrace fix #46
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Details will only be displayed if the 'env' option IS set, and it is set to something other than "production"
This is to allow consumers, particularly Expressive, to create a FinalHandler with configuration settings prior to the $response being available, and then inject the original response later. Otherwise, FinalHandler will always produce a 404 for successful requests, because any response it receives would differ from the original NULL response.
|
Addendum is a tiny bonus to fix another |
|
Just ran into this issue myself and then I remembered you mentioning this PR. This is a huge issue in my opinion, so hopefully it gets merged in soon. |
|
I'd do |
Never mind; that's how it already reads. 😄 |
|
Marking as 1.2.0, as it introduces new functionality. |
weierophinney
added a commit
that referenced
this pull request
Mar 17, 2016
…cktrace-fix Finalhandler production stacktrace fix
weierophinney
added a commit
that referenced
this pull request
Mar 17, 2016
Patch #39 added the method `testInvokingWithExceptionInNonProductionModeIncludesPrevTraceInResponseBody`. The test fails after adding the code from #46, as that code modifies `FinalHandler` to never provide exception details unless in non-production mode (which is the default). This patch updates the test to set the final handler used in the test setup to set the environment to development so that the expectations pass.
weierophinney
added a commit
that referenced
this pull request
Mar 17, 2016
|
Merged to develop for release with 1.2.0. |
|
👍 thanks!! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@weierophinney this addresses #45 and makes it possible to create the
FinalHandlerin a factory and worry about the original response later.One thing I wasn't sure about was whether error details should be in the case of
'env' !== 'production'vs.'env' === 'development'. Production is surely "NO" and development is surely "YES", but other environments like staging, qa, etc. may depend on the implementor. Perhaps a booleandisplay_error_detailsoption would be better thanenv? If so, what would you do with the originalenv? Remove it completely? Or automatically setdisplay_error_detailstotrueifenv != productionandfalseotherwise for BC?