-
Notifications
You must be signed in to change notification settings - Fork 27
Uncaught errors: When templating can't be loaded properly #73
Comments
@daum the Templating is a hard dependency because we render the mail using twig |
@benji07 Yep totally understand, which is why I was suggesting either making the rendering portion a try/catch and on failure it renders a much simpler email or something similar. |
@daum Can you paste a full stack trace for the error that prevents rendering? |
Yep will try to get it for you by end of week. It's not technically the rendering but the construction of the Twig service in this case with the specific FOSUser bundle version and integration with Twig's security extension. |
In this case adding a try-catch is not likely to help as the Note that this should probably be fixed on FOSUB side instead. |
It's actually not an issue in later renditions of FOSUserBundle. It just happened to be the one that led me to figuring out why we weren't getting notifications. Overall I think the bigger question is requiring that twig and it's related extensions all are able to load without error ok? As I mentioned I know this is a edge case, but I could see someone's custom twig extension causing a 500 error (ie can't connect to a DB on initialization) which being able to still receive error notifications would be beneficial. As you pointed out a try/catch around the render is not sufficient. We'd need to lazily call the templating engine and wrap that + the render in a try/catch. |
On a project recently we were getting times when we wouldn't be notified of errors. After digging into it a bit more it appears if the templating service has an error, then this bundle won't be notified of the error.
I believe the issue is that the constructor takes in the the templating engine. In our situation (FOS User bundle is installed) when the DB is down twig also fails. This is due to Twig's security extension which in turn creates the UserManager in FOSUserBundle (https://github.com/FriendsOfSymfony/FOSUserBundle/blob/v1.3.7/Doctrine/UserManager.php#L40). Calling
getRepository
has Doctrine try to get some meta information about the repository. This then triggers an exception as the DB is down/rejecting connections.As this has occurred as the templating service itself is created, the ErrorNotifierBundle is never able to get it's error hooks OR to handle the kernel exception/console exception events.
I know this is a very specific use case, and on a version of FOS that is a little older, however it does highlight that this bundle has a hard dependency on the Templating which isn't completely necessary to send an error alert like the mailer dependency.
What do you think about making the templating library optional. This way if an error occurs in creation of the templating service the bundle still can handle the error. I'm not sure the best way to remove this dependency as injecting a reference to the container is generally frowned upon, however I think in this case it may be warranted. Just going with the assumption that is how it is handled we could then do the following on https://github.com/Elao/ErrorNotifierBundle/blob/master/Listener/Notifier.php#L333 . Instead of just trying it without a Try/Catch wrap that in it's own try catch and call from the container the templating service. If if fails, send out an email with just the error message and perhaps a miniaturized stack trace?
The text was updated successfully, but these errors were encountered: