Open thomsentner opened 3 years ago
I've submitted a PR that seems to resolve this issue. As werkzeug.exceptions.abort
and flask.abort
are regularly used functions, I think these should be accounted for in Flask-MonitoringDashboard.
Simplified dummy code above for clarity.
Hi @thomsentner , thank you for bringing up this issue and taking the time to contribute to the Flask-MonitoringDashboard project.
As part of my school project, my team is conducting a usability research study to improve the dashboard. I noticed your experience with the app and thought it would be valuable to gather more insights from you.
Would you be open to receiving a few questions about your experience with Flask-MonitoringDashboard? It won't take more than 20 minutes to answer them. Your feedback will play a vital role in enhancing the app's functionality and addressing any existing limitations.
If you're interested, please let me know, and I will send you the questions. Your involvement would be highly valuable and greatly appreciated.
Describe the bug Responses initiated through
flask.abort
/werkzeug.exceptions.abort
are always logged as HTTP status code 500 by Flask-MonitoringDashboard, even when e.g.flask.abort(400)
is called.To Reproduce
When navigating to http://127.0.0.1:5001/dashboard/endpoint/1/status_code_distribution, a status code 500 is incorrectly logged.
Expected behavior The actual HTTP codes to be logged.
Desktop (please complete the following information): Flask==1.1.2 Flask-MonitoringDashboard==3.1.0