Connection reset after exception raised & handled in FastAPI #2285
-
|
Hi Uvicorn team, When using an exception handler in a FastAPI application, I am seeing subsequent requests terminated with the following issue: I've included a sample application, script, and tcpdump that can be used to reproduce the behavior. I'd appreciate some help understanding if this is something misconfigured on my side, or if this is a bug. Thanks. How to reproduceSample App from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
from starlette.status import HTTP_500_INTERNAL_SERVER_ERROR, HTTP_400_BAD_REQUEST
from pydantic import BaseModel, Field
from uvicorn import run
class Message(BaseModel):
message: str
app = FastAPI(title="Test app")
@app.post("/error")
def error(body: Message) -> JSONResponse:
raise Exception(body.message)
@app.post("/ok")
def ok(body: Message) -> JSONResponse:
return JSONResponse(status_code=200, content="ok")
@app.exception_handler(Exception)
async def catch_all_exception_handler(request: Request, exc: Exception) -> JSONResponse:
return JSONResponse(
status_code=HTTP_400_BAD_REQUEST, content={"detail": str(exc)}
)
if __name__ == "__main__":
run(app, host="127.0.0.1", port=8000)Sample client script from requests.sessions import Session
def main():
session = Session()
resp = session.post("http://127.0.0.1:8000/error", json={"message": "test error"})
assert resp.status_code == 400
resp = session.post("http://127.0.0.1:8000/ok", json={"message": "test error"})
if __name__ == "__main__":
main()Logs from the client script tcpdump of the server port while the client script is running Interesting Observations
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 17 replies
-
|
What are the logs from the server side? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if this is really an issue, because it looks the intended behavior to close the connection after an exception on the app's side... What I'm not sure is if we are able to check if a connection is being closed, or something. Also, if you retry after a second or something, it works, right? @tomchristie Do you have any insight if this is an issue? |
Beta Was this translation helpful? Give feedback.
-
|
Correct, if I insert even a short wait like import time
from requests.sessions import Session
def main():
session = Session()
resp = session.post("http://127.0.0.1:8000/error", json={"message": "test error"})
assert resp.status_code == 400
time.sleep(0.1)
resp = session.post("http://127.0.0.1:8000/ok", json={"message": "test error"})
if __name__ == "__main__":
main()I'm not sure about the intended behavior, but I can explain our use case if this helps. Our application code raises well-known exceptions like @app.exception_handler(Exception)
async def catch_all_exception_handler(
request: Request, exc: Exception
) -> JSONResponse:
if isinstance(exc, NotFoundException):
return JSONResponse(
status_code=HTTP_404_NOT_FOUND,
content=NotFoundError(detail=str(exc.detail)).model_dump(),
)
elif isinstance(exc, ValidationException):
return JSONResponse(
status_code=HTTP_400_BAD_REQUEST,
content=BadRequestError(detail=str(exc.detail)).model_dump(),
)
else:
return JSONResponse(
status_code=HTTP_500_INTERNAL_SERVER_ERROR,
content=InternalServerError(detail="").model_dump(),
) |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Kludex and @tomchristie, just wanted to follow up on this. What are next steps to determine if this is something that can be fixed? I'd be happy to attempt a PR if someone could point me in the right direction. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
After taking another look today, I actually think I figured this out. It turns out, Starlette treats exception handlers that handle For exception handlers that handle Then, Uvicorn closes the client connection: uvicorn/uvicorn/protocols/http/h11_impl.py Line 416 in a2219eb Switching our exception handler in the app to handle a more specific exception than |
Beta Was this translation helpful? Give feedback.
-
|
Neat work on isolating this more carefully... General rule here: We're not in a position to debug "x" other project. Ideally |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @tomchristie. Apologies, when I started I was not familiar with the Uvicorn/Starlette/FastAPI stack internals, so when I saw the TCP reset packets being sent to the client, I figured Uvicorn was the cause. Thanks for the help. |
Beta Was this translation helpful? Give feedback.
After taking another look today, I actually think I figured this out. It turns out, Starlette treats exception handlers that handle
Exceptiondifferently than handlers that handle more specific exceptions:https://github.com/encode/starlette/blob/89fae174a1ea10f59ae248fe030d9b7e83d0b8a0/starlette/applications.py#L92-L92
For exception handlers that handle
Exception, it uses aServerErrorMiddlewareclass, which at the end of handling the exception, re-raises it to the Uvicorn layer:https://github.com/encode/starlette/blob/89fae174a1ea10f59ae248fe030d9b7e83d0b8a0/starlette/middleware/errors.py#L186-L186
Then, Uvicorn closes the client connection:
uvicorn/uvicorn/protocols/http/h11_impl.py