Repository navigation
Can retrying a non-resumable Drive files.create after HTTP 502 create a duplicate? #2825
Description
The Drive error guide recommends retrying 5xx errors. When num_retries > 0, the Python client retries responses with status ≥500, including on its non-resumable request path.
For a multipart Drive files.create POST, could the file be created successfully but the client receive a 502? If so, repeating the request could create a duplicate file.
Is retrying a non-resumable files.create after a 502 safe? If it isn’t, what approach do you recommend for handling this ambiguous result?
Activity
NotAnyoneMe commentedon Sep 26, 2026
@tipa Short answer No
Why?
files.create multipart requests are non idempotent each request creates a new file with a different ID Google Drive does not have automatic deduplication
Scenario of problem
Client —POST /upload/drive/v3/files > Google
File created (ID: xxxx)
Infrastructure failure (Load Balancer)
Client —- 502 Bad Gateway > LB
python client sees num_retries > 0, retries requests
Client —POST /upload/drive/v3/files > Google
Second File created (ID: yyyyy)
The 502 came from Load Balancer not from Google’s backend meanwhile the first request successful but response not delivered
Recommended approach: use resumable upload
Switch uplodType=resumable the session URI acts as an idempotent token so retrying on the same session won’t create a duplicate
POST /upload/drive/v3/files?uploadType=resumable ← returns session URI
PUT {session_uri} + file bytes ← idempotent, safe to retry
If you must stay on multipart do a research before retry using a unique appProperties
Key:
POST /upload/drive/v3/files ← 502
GET /drive/v3/files?q=appProperties has { key='upload_key' and value='...' }
If the file is found > return it skip retry
if not found > retry is safe