I’m struggling with how to even handle this particular bug.
Does one parse the messages in every thread for certain keywords such as “myfiles_browser” because this condition does not raise an exception.
And in some cases, it seems like the same keywords aren’t even being used but the end result is the same: we could not read the files associated with this request.
I did
if ('re-upload' in last_content.lower()
or last_content.startswith("I apologize")
or last_content.startswith("Apologies")
or last_content.startswith("I'm sorry for the misunderstanding")
or "The file you've uploaded is not accessible with the tool that allows me to view" in last_content
or 'I’m sorry for the confusion, but it seems there was an issue with the file accessing tool.' in last_content
or 'myfiles_browser' in last_content):
Same error, it works in the playground but not with the API. It always mentions myfiles_browser, even though the file has been uploaded and I can see it within the files tab…
The fact that you have to re-upload a file over the playground to a thread and not use an existing file is suspicious. In combination with the fact that we are billed for every message this file is used (full token count) makes me belive that under the hood the whole file_ids stuff is not working yet.
I really think that they use the uploaded file, take the content and make it part of their internal messages… Or am I on the wrong track here?
I may take a similar approach as you! 
When this condition is True, how do you handle it? Add another thread saying that the files are actually there?
I have had limited success with this. The main issue is that APIs responses no longer follow the instructions, instead, it acts like a normal chatGPT
Hello everyone,
I’m seeing that we are all the same, we have tried making a delay between requests, calls through php (curl) and Python and nothing… 50% of responses the system returns the file access error. Hopefully it will be resolved soon or they will make some kind of statement.
Good luck to everyone!
I try again later and chalk it up to this being a beta product.
I have had good luck with stuffing this into the very first thread:
“You definitely have files in the assistant.”
By good luck do you mean works more often or works every time? Thanks for the pointer.
[the sound of knocking on wood plays in the background]
So far, no failures.
Do you get working annotations? When I try this, I don’t get the “myfiles_browser” error message from the model anymore. It replies and cites it sources with a syntax like 【13†source】, but without providing any annotations alongside.
"annotations": []
You have to retrieve the message object and parse the substrings of the annotations to see them. From the openAI Documentation:
# Retrieve the message object
message = client.beta.threads.messages.retrieve(
thread_id="...",
message_id="..."
)
# Extract the message content
message_content = message.content[0].text
annotations = message_content.annotations
citations = []
# Iterate over the annotations and add footnotes
for index, annotation in enumerate(annotations):
# Replace the text with a footnote
message_content.value = message_content.value.replace(annotation.text, f' [{index}]')
# Gather citations based on annotation attributes
if (file_citation := getattr(annotation, 'file_citation', None)):
cited_file = client.files.retrieve(file_citation.file_id)
citations.append(f'[{index}] {file_citation.quote} from {cited_file.filename}')
elif (file_path := getattr(annotation, 'file_path', None)):
cited_file = client.files.retrieve(file_path.file_id)
citations.append(f'[{index}] Click <here> to download {cited_file.filename}')
# Note: File download functionality not implemented above for brevity
# Add footnotes to the end of the message before displaying to user
message_content.value += '\n' + '\n'.join(citations)
I’m not using annotations yet, so I have not looked into it. Sorry!
Yes, the problem is that
message_content.annotations
is empty, even though the model is citing sources in its response.
I’ve noticed that including “add annotations” in your user message helps substantially the same way confirming the assistant has the files in question helps with the retrieval. I’d say try to beef up the description/instruction of the assistant with these additions. Also hopefully these issues are just the bugs of a beta version and will be fixed soon 
@logankilpatrick can you help solve this issue of PDF not working?
@abhinavgujjar FYI I was able to get around this error by introducing a timeout after uploading the files and before creating the assistant, e.g.
// Upload a file with an "assistants" purpose
const file = await openai.files.create({
file: fs.createReadStream('test.pdf'),
purpose: 'assistants',
})
// wait for the file to be processed
log('Waiting for file to process...')
await wait(2000)
// Add the file to the assistant
const assistant = await openai.beta.assistants.create({
A better solution may be to poll the files endpoint to check that the file is available there.
EDIT: This only worked for so long. Even after waiting for 10s and polling the files api, I ran into sporadic issues.
I have seen similar stuff. If you submit an empty message to a thread you can get back results like this. Data leakage? Security problem? Hallucination?
Beta is one thing…this API needs serious attention.
I fixed the issue by doing something like this when I create the thread :
return $this->openAi->threads()->createAndRun([
'assistant_id' => $this->assistantId,
'thread' => [
'messages' => [
[
'role' => 'user',
'content' => $message,
'file_ids' => $fileIds,
],
[
'role' => 'user',
'content' => 'try again',
'file_ids' => [],
],
],
],
]);
By appending a message “try again” after my first message, it does analyze the file.