Cryptic 500 Internal Server Error when testing ASGI app endpoint

[berzi]

I'm trying to test an endpoint of my ASGI app using pytest. For now I'm simply running client.simulate_post("/my/endpoint)" and doing nothing with it. The test succeeds, but regardless of what I put into the request, result.json is always {'title': '500 Internal Server Error'}.

This could very well mean that something in my endpoint is broken, which is why I want the test in the first place, but the trouble is that I get no information on what went wrong or where. I don't expect that to be in the response for obvious reasons, but even if I set a debugger breakpoint on the very first line of the endpoint's handler, it is never triggered, and looking around with the debugger on the simulate_post() call itself I couldn't figure out what is wrong either.

It would seem the error occurs before the request handler is even called, meaning something is wrong in my setup, but the simulate_post() call itself does not raise any exception or something inside it catches it and turns it into a 500 inside the response, effectively hiding the error and its cause. How could I debug this further?

[vytas7]

Hi @berzi! Yeah, one of the reasons behind this behaviour is that ASGI, unlike WSGI's wsgi.errors, doesn't define any stream for logging errors back to the server.

I find it useful to configure logging, e.g.,

import logging

logging.basicConfig(
    format='%(asctime)s [%(levelname)s] %(message)s', level=logging.INFO
)

You should now be able to see Falcon log the traceback in question.

[berzi]

Thank you for the very fast answer. That worked. Note for anyone who might have a similar issue: I also had to set pytest's log_cli = true for the logs to show up.

I think it would make sense to mention this caveat somewhere in the guide to testing on ASGI apps, not sure where though.

[vytas7]

We ought to at least add a FAQ item, and maybe link to it from the ASGI tutorial.

[ryuusama09]

has this issue been assigned or solved ? . If not then i would like to help

[vytas7]

Not assigned nor solved -- you're welcome to help!

[ryuusama09]

hi , regarding this , where can i start from ?. I have brief to almost no idea about this project

[vytas7]

Then you'll need to familiarize yourself with this issue and the whole project too :slightly_smiling_face:

Since this issue is more pertinent to the async flavour of Falcon, maybe you could take our ASGI tutorial for a spin to start with?

[techrajdeep]

I am looking for an issue for my first contribution . Can you help me here.

[vytas7]

Hi @techrajdeep! Yes -- same as in my comment just above, maybe you could take the ASGI tutorial and/or write a simple ASGI app and a test case for it, just to get the feeling of the problem @berzi reported.

Then it is about expanding our FAQ and/or tutorials.

[vytas7]

Hi again @berzi & @techrajdeep, just checking whether any of you are still interested in contributing to this issue?

[berzi]

At the moment, personally, no. I might if it's still unresolved if/when I start using the project more actively.

[vytas7]

Thanks for getting back @berzi. And sorry, I instead meant to highlight @ryuusama09 and @techrajdeep who expressed interest in working this :sweat_smile:

[Jayaprakash-dev]

Hey @vytas7, @berzi,

I've looked into the codebase, specifically examining how URI routes are added and how the Falcon app searches for a route. The issue might be linked to an internal server problem, possibly encountering an unhandled exception that prevented the fulfillment of the request. Alternatively, it could be related to not passing any data in the POST request.

I've tested the code for the POST request, ensuring it results in either a '400' or '404' error.

For instance, when initiating an HTTP POST request to a resource class named Images with the URI template /images, the app responds with a '400 - bad request' error or '405 - method not allowed' if you haven't registered an on_post request handler. On the other hand, if there's no registered resource class for the specified URI template, the app returns a '404 - path not found' error.

#[Ref]

[vytas7]

Hi @Jayaprakash-dev, and thanks for looking at this. I believe the issue here is not the 500-error itself, but inadequate documentation on how to set up logging so that the resulting tracebacks are not suppressed in this case, particularly for ASGI apps that (unlike WSGI) don't define any error stream.

So the question was whether anyone could contribute a (primarily documentation?) PR on how to better debug this.

[MRLab12]

@vytas7 I'm happy to help with this. Looking though the previous comments here, seems like the issue would just be updating documentation so that users can set up logging for debugging?

[vytas7]

Resolved in #2223