How BackgroundTasks FastAPI works in HuggingFace Space
Hello! I have a model on a private storage in spaces, which is deployed using docker, and api calls go through FastAPI. Task: since my model needs some time to respond, I decided to add the Background Tasks FastiAPI to the call (screenshot below). The server works fine locally - I send a request through curl (screenshot), I get a response message that the request is closed, and the code continues to work on the local machine, as can be seen from the logs. The problem: when I make the same request (when the server is deployed on spaces), then in the space logs there is only a receipt about the request, but it does not send a response back to curl and there are no logs to find out what the server is doing, I only see the CPU load (only so I I understand that it works), after some time an error about reconnecting comes to curl. When I started the model with smaller parameters for the test, everything was the same, while the server is working, the request does not come to curl, and there are no logs, only after some time (5 minutes) when everything is processed, curl comes with a message that the processing has just started and from. logs appear. How can I solve this problem, so that my program in spaces works the same as it does locally in runtime, and sends a response before calculating the value in the background task. As I understand it, the hugging face spaces block the flow?Screenshot 2024-10-01 at 13.34.121244×182 28 KBScreenshot 2024-10-01 at 13.34.301334×296 39.5 KBScreenshot 2024-10-02 at 11.31.421164×746 36.8 KBScreenshot 2024-10-02 at 11.37.593360×1122 110 KB
2024-10-02T08:55:31Z
It’s supposed to work, but I have no idea because I’ve never used it!Apparently we only need to work out the Endpoint API settings though…huggingface.coDeploying Your FastAPI Applications on Huggingface Via DockerA Blog post by Hemanth Sai Garladinne on Hugging FaceMedium – 6 Jun 23Building and Deploying a FastAPI App with Hugging FaceIntroductionReading time: 4 min read
2024-10-02T09:28:50Z
Good day! This is a bit not what I need, let me describe the problem a little more simply: my docker on spaces works fine, but the problem is related to a long task, in the example you gave me, it is loading data from a dataframe (in my case, loading it to a mongo database) - that is, what can be done for more than 5 minutes. How should my code work - the client sent a request to the server (in my case, a patch), but in order not to wait for a long answer, the client must receive a response that the process is being executed, and it was working in parallel on the server, but in the case of spaces, everything is the opposite - the server first processes and then sends a response that he added to the queue. Even if you skip my example - space hugging face blocks the process dear, that is, until it executes the code, does not send a response, writes logs, etc., so I need to find someone who can tell me more about the architecture of space hugging face so that I understand how it works execution of tasks, and how to make it parallel, without a process block. But I also appreciate your time, thank you very much for your help)
2024-10-02T09:48:24Z
Hello. Hmmm… I guess I was wrong.I thought HF’s Spaces port wasonly 7860available by default?Maybe the one that has to be set in the YAML part of the README.md.In your case, I don’t think the request is getting through to the Spaces program because even the error log isn’t changing.@not-lainDo you know anything about that?huggingface.coSpaces Configuration ReferenceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.FastAPI Routing Issue in Hugging Face SpacesSpacesHello everyone, 
I’ve deployed a FastAPI application on Hugging Face Spaces. Everything seems to be running smoothly, and there are no errors in the logs. However, when I try to access my endpoints via a browser or tools like Postman, I’m getting a “404 error” or a “Cannot POST” error. 
Here’s a brief overview of my setup: 

I have a FastAPI route defined as @app.get("/check_request") and another one as @app.post("/recommend").
My Dockerfile specifies the CMD as CMD ["uvicorn", "app:app", "--hos…
2024-10-02T10:54:05Z
Forgive me, I took not very good screenshots to show (I blurred out the confidential ones). Docker is deployed correctly, but local execution is not: running the test locally on my Mac (for example), the server sends a response and then executes the task on the server (Screenshot 1). The space server first executes the task (Screenshot 2) and then only sends a response (Screenshot 3) that executes the task, as if the face-hugging space stream is blocked at that moment, because of this (if the request is long) my curl throws an error.Screenshot 1:Screenshot 2024-10-02 at 13.38.432676×674 161 KBScreenshot 2:Screenshot 2024-10-02 at 13.40.382698×1116 177 KBScreenshot 3:Screenshot 2024-10-02 at 13.43.012722×658 136 KB