This repository was archived by the owner on Mar 31, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 31, 2026. It is now read-only.
Started getting random ValueError: Bad response: not multi-part exceptions #404
Copy link
Copy link
Closed
Labels
api: storageIssues related to the googleapis/python-storage API.Issues related to the googleapis/python-storage API.priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Description
Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.
Please run down the following list and make sure you've tried the usual "quick fixes":
- Search the issues already opened: https://github.com/googleapis/python-storage/issues
- Search StackOverflow: https://stackoverflow.com/questions/tagged/google-cloud-platform+python
If you are still having issues, please be sure to include as much information as possible:
Environment details
- OS type and version: Debian GNU/Linux 10 (buster)
- Python version: Python 3.7.7
- pip version: pip 21.0.1
google-cloud-storageversion: 1.37.0
Steps to reproduce
- I cannot reproduce this because it is happening periodically, and only in my production flask app, not even on the same docker image running in staging with less traffic. This makes me think its related to some threading related issue, but I can't isolate the problem.
- This problem started without any code changes on our side, and without changing the docker image, so something changed in the google cloud storage server response behavior that started triggering this sometime starting on March 30, and then ramping up in frequency on April 1st and 2nd.
Code example
I don't have a concise code example. But it's being triggered with
get_blob(key).
Stack trace
traceback: [
0: "Traceback (most recent call last):
"
1: " File "/usr/local/lib/python3.7/site-packages/flask/app.py", line 1950, in full_dispatch_request
rv = self.dispatch_request()
"
2: " File "/usr/local/lib/python3.7/site-packages/flask/app.py", line 1936, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
"
3: " File "/usr/local/lib/python3.7/site-packages/middle_auth_client/decorators.py", line 171, in decorated_function
return f(*args, **kwargs)
"
4: " File "/usr/local/lib/python3.7/site-packages/middle_auth_client/decorators.py", line 253, in decorated_function
return f(*args, **kwargs)
"
5: " File "./pychunkedgraph/app/meshing/v1/routes.py", line 75, in handle_get_manifest
return common.handle_get_manifest(table_id, node_id)
"
6: " File "./pychunkedgraph/app/meshing/common.py", line 204, in handle_get_manifest
flexible_start_layer=flexible_start_layer
"
7: " File "./pychunkedgraph/meshing/meshgen_utils.py", line 152, in get_highest_child_nodes_with_meshes
existence_dict = stor.files_exist(filenames)
"
8: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/storage/storage.py", line 584, in files_exist
self.wait(desc)
"
9: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/threaded_queue.py", line 234, in wait
self._check_errors()
"
10: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/threaded_queue.py", line 191, in _check_errors
raise err
"
11: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/threaded_queue.py", line 153, in _consume_queue
self._consume_queue_execution(fn)
"
12: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/threaded_queue.py", line 180, in _consume_queue_execution
fn()
"
13: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/storage/storage.py", line 575, in exist_thunk
results.update(interface.files_exist(paths))
"
14: " File "/usr/local/lib/python3.7/site-packages/cloudvolume/storage/storage_interfaces.py", line 240, in files_exist
result[file_path] = self._bucket.get_blob(key)
"
15: " File "/usr/local/lib/python3.7/site-packages/google/cloud/storage/batch.py", line 296, in __exit__
self.finish()
"
16: " File "/usr/local/lib/python3.7/site-packages/google/cloud/storage/batch.py", line 281, in finish
responses = list(_unpack_batch_response(response))
"
17: " File "/usr/local/lib/python3.7/site-packages/google/cloud/storage/batch.py", line 334, in _unpack_batch_response
raise ValueError("Bad response: not multi-part")
"
18: "ValueError: Bad response: not multi-part
Making sure to follow these steps will guarantee the quickest resolution possible.
Thanks!
Reacted by Sven Dorkenwald
Metadata
Metadata
Assignees
Labels
api: storageIssues related to the googleapis/python-storage API.Issues related to the googleapis/python-storage API.priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Activity
fcollman commentedon Apr 2, 2021
we hacked a more informative debug statement into the cloud-storage library in production and got this error.
fcollman commentedon Apr 2, 2021
This was not happening a month ago, and the error returned could be much more informative. Seems like the server is enforcing limits it wasn't in the recent past nor is the library helping the user understand the source of the problem.
danielduhh commentedon Apr 9, 2021
Thanks for the details @fcollman. We've seen this intermittent 413 error pop up recently in another case. I'm checking in with the internal API team to see if theres a service change that could be causing this and will get back to you as soon as I have something.
danielduhh commentedon Jul 9, 2021
Sorry for the late response. No changes from the API side that should cause this. @fcollman can you confirm that 1) you're still intermittently running into this error, and 2) your batch request content size is not greater than the max 10mb
tseaver commentedon Jul 13, 2021
I started to move down the path that this isn't a bug. However, the
Batch.finishmethod makes a low-level API call and does not check the top-level response code, which is a bug: it shouldn't try to unpack the sub-responses if the overall batch failed.fcollman commentedon Jul 13, 2021
ah.. sorry.. we did track down a root cause, which was an expired service account credential, though it wasn't clear from the error that this was the case, and it wasn't clear why it was so unreliable in its nature. Perhaps something to do caching of such things across GCS.
cojenco commentedon Sep 30, 2021
@fcollman Are you still running into this issue after refreshing the service account credentials?
There's also a fix made in v1.42.1 regarding intermittent 413 errors using batch requests.
fcollman commentedon Sep 30, 2021
when we fix the service account credentials the error goes away.. I'd still argue that JWT signature error or this valueerror isn't the most clear advertisement of what the underlying issue is.
cojenco commentedon Sep 30, 2021
Agreed, I've opened a tracking issue and will submit a fix shortly. Thanks for bringing this to our attention!