Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Debug][BC Break] Fixed deserialization of FlattenException by the Serializer component#33630
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
skalpa commentedSep 18, 2019
As I don't like the BC, even though you could consider it fixes an important problem in the class, I tried to find other fixes for#32719 (comment). If one of them seems more acceptable, I'll just close this and work on the alternate solution. |
skalpa commentedSep 19, 2019
As I found a better solution that maintains BC to the linked issue, I'm closing this. |
As spotted in#32719, the Serializer component is unable to deserialize some
FlattenExceptioninstances, which breaks the messenger component when used with the symfony serializer.While this can't be fixed in
FlattenExceptionwithout breaking BC, as the main/sole purpose of this class is to be serialization friendly, I thought it was a real issue.Also, it should only break classes that extend
FlattenExceptionand I couldn't find a single project on Github that does this, nor imagine why anyone would want to (actually, I believe this class should have been marked final).Here are all the issues I identified, and how they are fixed by this PR:
getHeaderscan returnnullorarray, butsetHeadershad anarraytype-hint: I removed the type hintgetPreviouscan returnnullorself, butsetPrevioushad aselftype-hint: I removed the type-hintsetTracerequired 3 arguments, and added a new frame to the trace: the file and line arguments are now optional, and I try to detect whether the passed trace has already been processed or not. This may not be the best thing to do IMHO, but an attempt to limit the BC break to subclasses and ensure usage of the class doesn't get broken.Note: The same issues affect the
FlattenExceptionclass of the new ErrorRenderer component, but I will submit an new issue to discuss the best solution here, as I would also like to discuss#32873 and propose an alternate solution to#32473.