I am seeing frequent errors like the one below. It doesn’t come all the time, but I am seeing it now and then. Any suggestions, as to why it could be coming and is there anything in the code I could do to avoid this?
Error running thread: Error: 400 Thread thread_i2sZwJuBCIe1vTCVOGRCFlgQ already has an active run run_HJY8MEOpt5CZgTXqqACWnPYq.
Wait for the run to finish
https://platform.openai.com/docs/assistants/how-it-works/thread-locks
I have been searching for the API which given a threadId would be able to tell if there is an active run on that thread or not. But haven’t been able to find such an API.
The option which comes to me is to keep track of each run in my db, and before adding a new message, I would need to retrieve the last run from my db and check its status. This is quiet a overhead.
Alternatively, I make the api call to list all runs for the thread, and check if all of them are completed. If I do this before each message, it could still add quiet a bit of processing overload.
Any suggestions on how to go about this? Is there a better alternative?
In the documentation I sent you:
You can optionally use Polling Helpers in our Node and Python SDKs to help you with this. These helpers will automatically poll the Run object for you and return the Run object when it’s in a terminal state.
From the documentation again:
If you are not using streaming, in order to keep the status of your run up to date, you will have to periodically retrieve the Run object. You can check the status of the run each time you retrieve the object to determine what your application should do next.
Stream the results if you want, or poll for the update. They usually arrive in less than a minute so you don’t need to deposit this information into a database and then periodically check the database. This is just adding extra work for no reason. I can understand tracking the status for some updates (to pass to the user), but this should be a part of your polling function
In reality it doesn’t make sense to add a message before the Assistant has responded anyways.
I’m going to assume you are trying to facilitate some sort of conversation flow between a user and a Assistant.
You’ll have to manage people who send multiple messages yourself. An easy way is to queue the messages and send them based on a debounce function. Then, like ChatGPT, you can block the message sending features until the thread is unlocked.
If you’re finding issues with the current framework you may need to step back and think about what you are implementing and why it feels like there’s a lot of friction between you and the service. You could use ChatCompletions, but you lose a lot of the features that Assistants provide & would probably (hopefully) end up using a similar system.
Thanks for this information, I surely prefer the assistant api to chat completions. Maybe I should switch to streaming.