https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27557 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27557 --- Comment #2 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 118293 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=118293&action=edit Bug 27557: Display stacktrace on 500 for superlibrarian

From pod for Plack::Middleware::StackTrace: """ Gathering the information for a stack trace via Devel::StackTrace is slow, and Devel::StackTrace::WithLexicals is significantly slower still. This is not usually a concern in development and when exceptions are rare. However, your application may include code that's throwing and catching exceptions that you're not aware of. Such code will run significantly slower with this module. """ Maybe we should avoid the stacktrace and prefer to retrieve the error only, without the stacktrace? (but how?)

cp C4/Auth.pm /usr/share/koha/lib/C4/Auth.pm cp debian/templates/plack.psgi /etc/koha/sites/kohadev/plack.psgi cp errors/500.pl /usr/share/koha/intranet/cgi-bin/errors/500.pl cp koha-tmpl/intranet-tmpl/prog/en/modules/errors/errorpage.tt /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/modules/errors/errorpage.tt restart_all -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27557 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #3)

Any ideas how we could retrieve the original error (vs the whole stacktrace)?

Based on my comment from https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26048#c29, I think we would need to replace Plack::Middleware::HTTPException with our own custom error handling middleware. Looking at the patch here, I would remind folk that the StackTrace middleware is only recommended for development and not production: "You're recommended to use this middleware during the development and use Plack::Middleware::HTTPExceptions in the deployment mode as a replacement" (https://metacpan.org/pod/Plack::Middleware::StackTrace). But the concept used by StackTrace (ie $env->{'plack.stacktrace.text'} = $text;) is what I would suggest. Ultimately, write a middleware that catches the error using eval{} or try/catch, save the error to an environmental variable, print the error to psgi.errors, and then move on to the ErrorDocument middleware. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27557 Lillian <l.curanzy@newportlibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |l.curanzy@newportlibrary.or | |g -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27557 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #5 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- It would also be nice if we could give more librarian-centric error messages that aren't behind a syspref. For example, errors triggered by a bib or item missing a field assumed to always have a value ( itype, I'm looking at you ). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27557 --- Comment #7 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- (In reply to David Cook from comment #6)

Looking at this again and wouldn't the best solution be to improve our coding practices to gracefully handle errors in context-specific situations?

Yes, and being able to get those errors from librarians would make finding and handling those errors much easier. I wish we had some real world examples. To continue off my itype example, there are times we can know ahead of time that an unpopulated itype will trigger and error, and times we may not know. We can probably use transactions to more gracefully handle unknowns at the cost of performance. What may be a good solution halfway between giving user's entire stack traces and giving them a generic 500 error would be something along the lines of what CloudFlare does where the user is present an id ( named Ray ID in the case of CloudFlare ) and we can store the full stack trace in the database with the corresponding ID. That way the librarian or patron can make a report with the ID to the library IT staff or support organization. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.