-
-
Notifications
You must be signed in to change notification settings - Fork 313
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
Fix TraceableFileLocator
#894
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for contribution! I left one suggestion for more test cleanup.
Best, Marcin
2e88111
to
0c653ae
Compare
I think this is ready. |
im sorry if it took me this long to answer, could you please rebase this? |
0c653ae
to
bb3eb6c
Compare
Sure, done. I don't think the CI failure is related to this PR. It's the same as in #893. |
Should be fixed by #901 |
Can this be considered a duplicate of #900? |
I'm not sure, I tend to no. |
bb3eb6c
to
e56a30c
Compare
I'm sorry , now i remember what was this about. i forgot to commit it in the jms/metadata package. it was supposed to be a new feature that allows you to know which files were attempted to be loaded when looking for metadata ( a common problem i saw in many invalid bug reports). I will adjust it as soon as I can. Thanks! |
thanks |
The
TraceableFileLocator
, which was introduced in #858, to log some data for Symfony's profiler panel, was broken. It implemented a method that doesn't exist anywhere in the project and thus never gets called, so nothing is logged. In the profiler panel you may think everything's alright, though, as the messageif this list is empty, probably all the data are cached as expected
gets displayed, which is probably even true most of the time.The new
TraceableFileLocator
now also decorates the original one, instead of extending it, which makes it more flexible in case someone else wants to decorate theFileLocator
, too.