File API list ServerError: 500 INTERNAL

Google Cloud Build with AI Custom ML & MLOps
1

Hey guys,

I got a error using File API from google-genai. I use that to list and delete files in the generative language API file storage. After using it for some time, I received this generic error and since then I have not been able to list anything, all requests fail.

Function: client.files.list()

Error: ServerError: 500 INTERNAL. {‘error’: {‘code’: 500, ‘message’: ‘Failed to convert server response to JSON’, ‘status’: ‘INTERNAL’}}

Stack:

---------------------------------------------------------------------------
ServerError                               Traceback (most recent call last)
Cell In[8], line 2
      1 print('My files:')
----> 2 for f in client.files.list():
      3     client.files.delete(name=f.name)

File ~/xxx/google/genai/files.py:714, in Files.list(self, config)
    708 def list(
    709     self, *, config: Optional[types.ListFilesConfigOrDict] = None
    710 ) -> Pager[types.File]:
    711   return Pager(
    712       'files',
    713       self._list,
--> 714       self._list(config=config),
    715       config,
    716   )

File ~/xxx/google/genai/files.py:385, in Files._list(self, config)
    382 request_dict = _common.convert_to_dict(request_dict)
    383 request_dict = _common.encode_unserializable_types(request_dict)
--> 385 response_dict = self._api_client.request(
    386     'get', path, request_dict, http_options
    387 )
    389 if not self._api_client.vertexai:
    390   response_dict = _ListFilesResponse_from_mldev(
    391       self._api_client, response_dict
    392   )

File ~/xxx/google/genai/_api_client.py:732, in BaseApiClient.request(self, http_method, path, request_dict, http_options)
    722 def request(
    723     self,
    724     http_method: str,
   (...)
    727     http_options: Optional[HttpOptionsOrDict] = None,
    728 ) -> Union[BaseResponse, Any]:
    729   http_request = self._build_request(
    730       http_method, path, request_dict, http_options
    731   )
--> 732   response = self._request(http_request, stream=False)
    733   json_response = response.json
    734   if not json_response:

File ~/xxx/google/genai/_api_client.py:661, in BaseApiClient._request(self, http_request, stream)
    658 print(data)
    660 print(response.content)
--> 661 errors.APIError.raise_for_response(response)
    662 return HttpResponse(
    663     response.headers, response if stream else [response.text]
    664 )

File ~/xxx/google/genai/errors.py:103, in APIError.raise_for_response(cls, response)
    101   raise ClientError(status_code, response_json, response)
    102 elif 500 <= status_code < 600:
--> 103   raise ServerError(status_code, response_json, response)
    104 else:
    105   raise cls(status_code, response_json, response)

ServerError: 500 INTERNAL. {'error': {'code': 500, 'message': 'Failed to convert server response to JSON', 'status': 'INTERNAL'}}

I can also replicate it by making a GET call directly using the following cURL:

curl --location ‘https://generativelanguage.googleapis.com/v1beta/files’ \ --header 'x-goog-api-key: <my_api_key>

Since I can’t list and delete, my storage has filled up to the maximum. When the quota resets, the storage is cleared and this error disappears, but it comes back after calling the file API to list and delete a few dozen/hundreds of times.

Anyone felt the pain?

Tnks,

2

Hi Alano_Pinto_MP,

The repeated nature of the error after a certain number of calls suggests a possible issue with rate limiting or quotas that isn’t being communicated with a standard 429 Too Many Requests error. The Gemini API has documented rate limits, which are measured in requests per minute (RPM) and tokens per minute (TPM). Exceeding these limits could potentially trigger an internal server error.

You may implement exponential backoff in your code. This involves retrying a failed request with an increasing delay between each attempt. This can help mitigate issues related to hitting rate limits. While the error is a 500, which typically indicates a server-side problem, implementing this is a good practice for handling API requests.

With regard to file listing and deletion logic, the problem appears to be triggered by a high volume of list and delete operations. It’s possible that rapid, successive calls to these functions are causing an unstable state on the server.

Instead of listing and then deleting in a tight loop, consider a different approach. If the goal is to clear all files, it might be more stable to retrieve a list of files once, and then iterate through that local list to perform deletions with pauses in between.

Also, the Gemini API automatically deletes files after 48 hours. Relying on this automatic cleanup might be a temporary workaround if you are unable to delete files manually due to the error. However, this is not ideal if you need to manage your storage more granularly to stay within the 20 GB per-project limit.

If your workflow allows, you might be able to structure your file usage to work within the 48-hour automatic deletion window, reducing the need for frequent manual deletions.

In addition, here are some similar cases you might find helpful:

If the issue persists, contact Google Cloud Support and provide detailed information.