Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Issue] improve exception handling in Layout render #29606

Closed
4 tasks
m2-assistant bot opened this issue Aug 17, 2020 · 2 comments · Fixed by #27478
Closed
4 tasks

[Issue] improve exception handling in Layout render #29606

m2-assistant bot opened this issue Aug 17, 2020 · 2 comments · Fixed by #27478
Labels
Component: View Fixed in 2.4.x The issue has been fixed in 2.4-develop branch Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S3 Affects non-critical data or functionality and does not force users to employ a workaround.
Projects
Community Backlog

Comments

@m2-assistant
Copy link

m2-assistant bot commented Aug 17, 2020 •
edited by engcom-Alfa
Loading

This issue is automatically created based on existing pull request: #27478: improve exception handling in Layout render

Preconditions (*)

When layout is being rendered in production mode, all exception messages are logged to system log as critical issues. However exception stack is lost. If we pass exception to LoggerInterface::critical instead this data will be saved to var/report.

Steps to reproduce (*)

  1. Add throw \Exception('test'); in a template.
  2. Validate that after rendering such a template, exception stack is being saved to var/report in addition to its message being logged.

Actual Result: (*)

✖️ All exception messages are logged to system log

Expected Result:

✔️ Messages should be logged to the exception log file

Questions or comments

  1. Is passing Exception to LoggerInterface::critical a preferred way of logging issues? (I see it being used this way in other places)
  2. Was saving non translated message in case of LocalizedException adding any value?

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds are green)
@m2-assistant m2-assistant bot added Component: View Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Severity: S3 Affects non-critical data or functionality and does not force users to employ a workaround. labels Aug 17, 2020
@fsw fsw mentioned this issue Aug 17, 2020
Merged
5 tasks
@ghost ghost added this to Ready for QA in Community Backlog Aug 17, 2020
@ghost ghost moved this from Ready for QA to PR In Progress in Community Backlog Aug 17, 2020
@magento-engcom-team magento-engcom-team added the Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed label Aug 17, 2020
@magento-engcom-team magento-engcom-team added Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed and removed Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed labels Aug 18, 2020
@engcom-Alfa engcom-Alfa added Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch labels Aug 18, 2020
@magento-engcom-team magento-engcom-team added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label Aug 18, 2020
@magento-engcom-team
Copy link
Contributor

✅ Confirmed by @engcom-Alfa
Thank you for verifying the issue. Based on the provided information internal tickets MC-36821 were created

Issue Available: @engcom-Alfa, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

@ghost ghost moved this from PR In Progress to Ready for Dev in Community Backlog Aug 18, 2020
@magento-engcom-team magento-engcom-team added the Fixed in 2.4.x The issue has been fixed in 2.4-develop branch label Aug 19, 2020
@magento-engcom-team
Copy link
Contributor

Hi @m2-assistant[bot]. Thank you for your report.
The issue has been fixed in #27478 by @fsw in 2.4-develop branch
Related commit(s):

The fix will be available with the upcoming 2.4.1 release.

@ghost ghost moved this from Ready for Dev to Done (last 30 days) in Community Backlog Aug 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Component: View Fixed in 2.4.x The issue has been fixed in 2.4-develop branch Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S3 Affects non-critical data or functionality and does not force users to employ a workaround.
Projects
No open projects
Community Backlog
  
Done (last 30 days)
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

improve exception handling in Layout render fsw/magento2
2 participants
@magento-engcom-team @engcom-Alfa