Hello,
I am experiencing a reproducible issue with the Gemini API File Search fileSearchStores.importFile operation.
The issue occurs when importing specific real-world Knowledge files into an existing File Search Store.
Environment
File Search Store:
fileSearchStores/staffstorestore001-0codvnfsuz76
The same store already contains documents that successfully reached STATE_ACTIVE.
The upload implementation uses the following official flow:
- Upload the original file to the Files API
- Confirm the Files API file is ACTIVE
- Call
fileSearchStores.importFile - Monitor the returned Operation
- Confirm the resulting File Search document reaches STATE_ACTIVE
- Delete the temporary Files API file only after successful completion
No file splitting, text reduction, format conversion, or fallback upload path is being used.
Failing file
File type:
text/plain (UTF-8)
File size:
113,962 bytes
Character count:
approximately 39,240 characters
The file is valid normal UTF-8 text.
The Files API upload succeeds.
Example Files API resource from the previous reproduction:
files/l1lv58q9b266
Files API state:
ACTIVE
The uploaded file size/hash was also confirmed to match the original file.
Failure
When the ACTIVE Files API resource is imported into the File Search Store using fileSearchStores.importFile, the request fails with:
HTTP 503
Response:
{
“error”: {
“code”: 503,
“message”: “Failed to count tokens.”,
“status”: “UNAVAILABLE”
}
}
In the previous minimal REST reproduction, the request failed after approximately 80 seconds.
No Operation resource was returned.
Therefore the failure occurs before Operation monitoring and before the document can reach STATE_ACTIVE.
Tokenization checks
The same text content was independently tested successfully with token counting.
Observed results:
gemini-3.8-flash countTokens:
21,619 tokens
gemini-embedding-001 countTokens:
20,944 tokens
Embedding itself also succeeded.
Therefore, the text can be tokenized successfully through these APIs, although I cannot determine which internal component is returning the File Search “Failed to count tokens” error.
Why this does not appear to be a simple file-size or file-format limit
We have successful File Search registration results in the same environment for other files.
Examples include:
- text/plain file of approximately 105,600 bytes → successfully registered
- DOCX containing approximately 2,200 paragraphs / ~678.9 KB uncompressed text content (actual DOCX file approximately 19.9 KB) → successfully registered
- Other DOCX Knowledge documents → STATE_ACTIVE
We have also observed both successful and failing TXT files and successful and failing DOCX files.
Therefore the behavior does not appear to correlate simply with TXT vs DOCX or a ~50 KB file-size threshold.
Reproduction after project/API key recovery
Separately, the Google Cloud project/API key experienced a restriction issue.
That issue has now been recovered, the old API key was replaced, and the Cloud Run application/API access is operational again.
After recovery, I did NOT modify the File Search upload code.
I verified that the implementation still uses exactly:
Files API upload
→ fileSearchStores.importFile
→ Operation monitoring
→ STATE_ACTIVE confirmation
→ temporary Files API file deletion after success
I then performed only one new upload attempt with the same failing Knowledge file.
The File Search registration failed again with HTTP 503.
I have stopped repeated retries to avoid unnecessary API traffic and possible automated restrictions.
Expected behavior
A valid Files API resource in ACTIVE state should be imported into the File Search Store, return an Operation, and eventually create a File Search document that reaches STATE_ACTIVE.
Actual behavior
Files API upload:
SUCCESS / ACTIVE
fileSearchStores.importFile:
HTTP 503 / “Failed to count tokens”
Operation:
NOT RETURNED
File Search document STATE_ACTIVE:
NOT REACHED
Could someone from the Gemini API / File Search team please investigate what condition causes fileSearchStores.importFile to return “Failed to count tokens” for specific valid files?
I can provide additional request details, timestamps, resource names, and a minimal reproduction if needed.
Thank you.