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?
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…
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)
Hello. Hmmm… I guess I was wrong.
I thought HF’s Spaces port was only 7860 available 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-lain Do you know anything about that?
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 2:
Screenshot 3:
