Upgraded Pyramid and other modules, now tracebacks are broken

[Ben Sizer]

I upgraded Pyramid from 1.5.1 to 1.5.2, and upgraded a few other packages too. Now I no longer get tracebacks when there is an error, just a 500 screen and a debug toolbar that does not allow me to view the traceback.

I'd run Pyramid under the debugger to find out what is going wrong, but that doesn't seem possible since it uses pserve.exe instead of a Python script to run.

Judging by the logging, something is breaking early on before the request is created. I suspect the session system, but I allow exceptions to fall out of there and Pyramid isn't showing that exception to me in any form. The logs I do see indicate that the following happens when I request the front page of my app: it attempts to get a session, then calls the view function, then attempts to get a session again (perhaps because I try to access request.authenticated_userid, which probably doesn't exist yet), then exits the view function (via an exception).

What do I have to do to see these exceptions? Either in the console, or the traceback in the Debug toolbar?

[Ben Sizer]

Looks like I can still get tracebacks if I fix the issues that cause the session to throw (DB inaccessible), but why not otherwise?

[Bert JW Regeer]

There is not enough information for us to know whether you are catching the exception somewhere, or have it set as the context on a view.

Bert

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Ben Sizer]

Thanks for your reply.

I wouldn't know how to catch the exception any further upstream. I add the routes (in this case mapping 'front_page' to '/'), call make_wsgi_app, that gets run by paste/pserve (I assume), and it invokes my view function (front_page) when I point a browser at the site. That is defined as such:

@view_config(route_name='front_page', renderer='front_page.mako')
def front_page(request):
     logged_in_user = request.authenticated_userid

And if that first line throws (because authenticated_userid has never been filled in), I never get a traceback.

[Jonathan Vanasco]

I've never used Pyramid under windows, so I could be off here...

But when running under Mac/Linux, one can trip 500x error that just says "Invalid Request" (or similar) under a few scenarios:

• exceptions in the wsgi middleware stack

• exceptions in most areas of the debugtoolbar code

• exceptions in very few areas of pyramid code (I think mostly in certain Events and Tweens)

For the debugtoolbar to work (and show you the traceback) it needs to catch the exception. It can't catch the middleware errors, and raising exceptions in certain parts of pyramid code will not have a proper environment for the tracebacks to work.  So these errors appear in the process log, but are inaccessible to the toolbar/interactive traceback mechanism.  It sounds to me like this is what you're experiencing.

Are you using any Event Subscribers ?  ( I think I've triggered stuff like this with NewResponse can cause this )  I recall tweens having issues too.   I think I also caused this with an exception in an __init__() function when using Class-based views.

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/13/2014 05:59 PM, Ben Sizer wrote:
> Thanks for your reply.
>
> I wouldn't know how to catch the exception any further upstream. I add
> the routes (in this case mapping 'front_page' to '/'), call
> make_wsgi_app, that gets run by paste/pserve (I assume), and it
> invokes my view function (front_page) when I point a browser at the
> site. That is defined as such:
>
> @view_config(route_name='front_page', renderer='front_page.mako') def
> front_page(request): logged_in_user = request.authenticated_userid
>
> And if that first line throws (because authenticated_userid has never
> been filled in), I never get a traceback.

I don't have my knowledge of the traceback handling swapped in, but I do
know that if you expect an 'authenticated_userid', you need to protect
the view with a permission: pyramid doesn't authenticate users in
unprotected views. OTOH, in that case, the 'authenticated_userid' would
be None (and not raise an error).

What version of Pyramid are you running? The 'authenticated_userid'
attribute was added to the request in 1.5a3.



Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlSPE6IACgkQ+gerLs4ltQ6bKgCg2b7VOJxiJwDnFAUH86BqRQA0
EVIAn30ejR+C9kS7NzDAx7VVCfVN129m
=wzlv
-----END PGP SIGNATURE-----

[Ben Sizer]

I forgot to mention I was using Windows, so, good guess. ;)

Anyway, this post inspired me to dig deeper and sprinkle some logging in there liberally. And I've found the change: at one point, I catch pymongo.errors.ConnectionFailure and raise pyramid.httpexceptions.HTTPInternalServerError in its place. In the past, I remember this still giving me a full traceback in development mode - not on-screen, where it shows a plain 500 page, but in the debug toolbar. Now it does not.

I can't see any indication in the changelog of this behaviour having changed though. Am I misremembering how it used to work? Is there any worth in explicitly throwing server errors like this if there is no logging that goes along with it?

[Chris McDonough]

On 12/16/2014 12:59 PM, Ben Sizer wrote:
> I forgot to mention I was using Windows, so, good guess. ;)
>
> Anyway, this post inspired me to dig deeper and sprinkle some logging in
> there liberally. And I've found the change: at one point, I catch
> pymongo.errors.ConnectionFailure and raise
> pyramid.httpexceptions.HTTPInternalServerError in its place. In the
> past, I remember this still giving me a full traceback in development
> mode - not on-screen, where it shows a plain 500 page, but in the debug
> toolbar. Now it does not.
>
> I can't see any indication in the changelog of this behaviour having
> changed though. Am I misremembering how it used to work? Is there any
> worth in explicitly throwing server errors like this if there is no
> logging that goes along with it?

If you're catching a pymongo ConnectionFailure and turning it in to an
HTTPInternalServerError, Pyramid's "default exception response view" is
going to render it because that exception inherits from
pyramid.httpexceptions.HTTPException which the default exception
response view is also registered for, and no traceback will be shown
(and certainly not the original traceback, which is lost when you catch
it and reraise). I can't remember a time when this was not true.

- C

>
>
>
> On Monday, 15 December 2014 16:30:45 UTC, Jonathan Vanasco wrote:
>
>
> I've never used Pyramid under windows, so I could be off here...
>
> But when running under Mac/Linux, one can trip 500x error that just
> says "Invalid Request" (or similar) under a few scenarios:
>
> • exceptions in the wsgi middleware stack
> • exceptions in most areas of the debugtoolbar code

> • exceptions in very few areas of pyramid code(I think mostly in

> certain Events and Tweens)
>
> For the debugtoolbar to work (and show you the traceback) it needs
> to catch the exception. It can't catch the middleware errors, and
> raising exceptions in certain parts of pyramid code will not have a
> proper environment for the tracebacks to work. So these errors
> appear in the process log, but are inaccessible to the
> toolbar/interactive traceback mechanism. It sounds to me like this
> is what you're experiencing.
>
> Are you using any Event Subscribers ? ( I think I've triggered
> stuff like this with NewResponse can cause this ) I recall tweens
> having issues too. I think I also caused this with an exception in
> an __init__() function when using Class-based views.
>

> --
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pylons-discus...@googlegroups.com

> <mailto:pylons-discus...@googlegroups.com>.

> To post to this group, send email to pylons-...@googlegroups.com

> <mailto:pylons-...@googlegroups.com>.

[Ben Sizer]

Yeah, I can see from the code that it won't render a traceback (which is probably why I chose to catch and rethrow it), but I was expecting to see one from the debug toolbar saying where the 500 was raised from. (Which is why I asked if there is any point to being able to raise these error exceptions if the system doesn't attempt to note that you did so.)

Apologies if I'm just completely misremembering this. It's possible that I added the catch-and-raise code near the end of the time I was last working on this project and just never saw what happens when it was triggered.

> <mailto:pylons-discuss+unsub...@googlegroups.com>.

[Chris McDonough]

On 12/16/2014 01:29 PM, Ben Sizer wrote:
> Yeah, I can see from the code that it won't render a traceback (which is
> probably why I chose to catch and rethrow it), but I was expecting to
> see one from the debug toolbar saying where the 500 was raised from.

No. When an exception view "catches" an exception, the exception view
renders something, and the exception doesn't bubble up outside of
Pyramid-proper (the toolbar is "outside" of Pyramid in this case).

> (Which is why I asked if there is any point to being able to raise these
> error exceptions if the system doesn't attempt to note that you did so.)

You can register an exception view for a particular kind of exception
and log, or do whatever else.

> Apologies if I'm just completely misremembering this. It's possible that
> I added the catch-and-raise code near the end of the time I was last
> working on this project and just never saw what happens when it was
> triggered.

Sure.

- C

> > an email to pylons-discus...@googlegroups.com <javascript:>
> > <mailto:pylons-discus...@googlegroups.com <javascript:>>.

> > To post to this group, send email to pylons-...@googlegroups.com

> <javascript:>
> > <mailto:pylons-...@googlegroups.com <javascript:>>.

> > Visit this group at http://groups.google.com/group/pylons-discuss

> <http://groups.google.com/group/pylons-discuss>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pylons-discus...@googlegroups.com

> <mailto:pylons-discus...@googlegroups.com>.