Downloads from all Google domains fail intermittently since Sep 25 (UNREACHABLE_INPUT_FILE)

[ligun0510]

Since Sep 25, 2026, around 08:00 UTC, most of our commands fail with UNREACHABLE_INPUT_FILE whenever the input file is hosted on a Google domain. Nothing changed on our side — the same pipeline had a 97–100% success rate for weeks.

Daily numbers from our account:

Sep 20:  43 commands,  43 success,   0 unreachable
Sep 22:  85 commands,  78 success,   0 unreachable
Sep 24:  67 commands,  60 success,   7 unreachable
Sep 25: 106 commands,  52 success,  53 unreachable   <-- starts here
Sep 26: 163 commands,  39 success, 123 unreachable
Sep 27: 126 commands,  32 success,  94 unreachable

It is intermittent. Eight identical commands, same input URL, submitted within one minute — three succeeded, five failed:

• SUCCESS 90513d3c-090c-4abe-8e85-6e0de99f200d, da0e569b-549c-406d-8d49-9229e8ab2f56, 022373cb-513b-4c02-a03e-5702dbe47e0c
• FAILED a61f8dcd-6630-4bc3-bab5-2f6f9f989762, 624c3a86-9899-4e87-b0b1-65f82a305ee5, 5a484b62-2358-48be-b128-ad11e91e9250

Every Google host fails, including Cloud Storage and the Drive API:

Input host | Command id | Result -- | -- | -- drive.google.com/uc?export=download | fca11f37-7d1c-4e8b-8ad2-0ea8b6af88be | UNREACHABLE_INPUT_FILE drive.usercontent.google.com/download | b256207f-5fa9-4ae1-97be-d21cb737f2bd | UNREACHABLE_INPUT_FILE docs.google.com/uc?export=download | 72dd7ef1-2382-4430-95e8-36cdc3c40a83 | UNREACHABLE_INPUT_FILE www.googleapis.com/drive/v3/…?alt=media | c89c8133-8259-488c-b630-1447e5508a6b | UNREACHABLE_INPUT_FILE storage.googleapis.com (public bucket) | f508fbd3-258f-40ac-9538-eccf88f22a1d | UNREACHABLE_INPUT_FILE

Ruled out on our side: files are shared with anyone-with-link and download fine from a browser, from a datacenter IP and with no User-Agent; your workers do follow redirects and do not need a file extension in the path (see the httpbin command); it is not file-specific — six of fourteen source files have both SUCCESS and FAILED runs.

Looks like Google is rate-limiting or blocking part of your egress range. Can you check which egress IPs the failed commands used? Is anyone else seeing this with Google-hosted inputs?

[peternaf]

Google Drive has an internal rate limit for accessing the same file multiple times.

If you have files you need Rendi to process multiple times, it's better to upload/store them in Rendi and use them from Rendi instead of Drive.

I couldn't see Google storage links in the commands you sent (I assume you are referring to Google Cloud bucket storage?) - feel free to send over specific commands for that (and not google drive) and we will check

[ligun0510]

1. The Google Cloud Storage command you asked for

f508fbd3-258f-40ac-9538-eccf88f22a1d — input was
https://storage.googleapis.com/gtv-videos-bucket/sample/ForBiggerBlazes.mp4
That is Google's own public demo bucket, not Drive. Result: UNREACHABLE_INPUT_FILE.

Also c89c8133-8259-488c-b630-1447e5508a6b — input https://www.googleapis.com/drive/v3/files/…?alt=media (Drive API, not a Drive share link). Same error.

For contrast, bedc39d7-17a7-41c4-8d45-e4a52a87c230 points at a Google Cloud Run endpoint and fails with UNSUPPORTED_FILE_FORMAT — meaning the download itself succeeded there.

2. Most failures are on the FIRST ever access to a file

Our pipeline takes a new video, processes it once and deletes it. Files are not reused. From today's 154 commands (16 distinct source files), looking only at the first time each file was ever requested:

first access succeeded: 5 files
first access failed with UNREACHABLE_INPUT_FILE: 11 files
Examples, all different files, hours apart, each the first request for that file:

03:20:05 37108c84-45e4-4f4c-b281-504798db84f5
04:26:05 a15a3811-927a-4a9a-b663-46183971d42f
04:47:07 1d8b95eb-0d92-475c-91b6-4bd93289c359
05:30:05 1d512f21-ec7b-413c-8624-174d9e113a31
05:50:05 251966a9-e38c-45b8-a827-650c1c4f4d4f
05:53:03 88228330-a45b-4c2a-babe-3fa9213166fd
Repeat requests exist only because we retry after a failure.

3. Same file, same minute, two sources

We uploaded one video to Rendi storage and ran 12 interleaved commands within 8 seconds — identical bytes, identical command:

storage.rendi.dev → 6 of 6 succeeded
drive.google.com → 2 of 6 succeeded, 4 × UNREACHABLE_INPUT_FILE
Repeated today: Rendi storage 6/6, Drive 2/10.

Account-wide success rate has been 23–27% every day since Sep 25, versus 97–100% before that. Nothing changed on our side.

Could you check which egress IPs your workers used for the failed commands? From here it looks like Google is rate-limiting or blocking part of your egress range, and the affected share is fairly stable.

[peternaf]

I am getting access denied from my own browser in incognito to: https://storage.googleapis.com/gtv-videos-bucket/sample/ForBiggerBlazes.mp4

[peternaf]

https://www.googleapis.com/drive/v3/files/%E2%80%A6?alt=media - this link returns:
{
"error": {
"code": 403,
"message": "The request is missing a valid API key.",
"errors": [
{
"message": "The request is missing a valid API key.",
"domain": "global",
"reason": "forbidden"
}
]
}
}

Please make sure the files you are sending Rendi are indeed accessible.

Please send the command ID from the first time you accessed a publicly accessible drive file and rendi couldn't reach it. Important: the first time you are using that file.

[ligun0510]

Update: solved on our side. Drive files are fine; only the Drive share-link hosts fail

Thanks for pushing back. First, a correction to my earlier messages:

• The GCS sample bucket really isn't public anymore. Please disregard that example.
• The googleapis.com/drive/v3/… example had a deliberately invalid key. I later found that Rendi reports any HTTP error as UNREACHABLE_INPUT_FILE (I checked with httpbin.org/status/403 and /404), so that example proved nothing.

So the title is wrong: not all Google domains fail. www.googleapis.com and storage.googleapis.com download fine from your workers. What fails is the Drive share-link hosts (drive.google.com, drive.usercontent.google.com).

Same account, same files, same commands, Sep 30 (UTC):

Input URL | Result -- | -- https://drive.google.com/uc?id=&export=download | 07:00–08:33: 389 commands, 0 successes, all UNREACHABLE_INPUT_FILE https://www.googleapis.com/drive/v3/files/?alt=media&key= | 08:26–09:31: 24 of 24 downloaded and rendered, logo inputs included. Zero UNREACHABLE_INPUT_FILE

In a side-by-side test (one file, same minute, 8 commands for each URL form) the share link got 0/8 and the API URL got 8/8. Ten more commands in the second window failed with REQUIRED_FILES_NOT_SPECIFIED, but that was a bug in our own input count and has nothing to do with downloading.

On the rate-limit explanation: through the API endpoint, one of these files was fetched 11 times within an hour, and all 11 succeeded. So repeated access to the same file doesn't look like the problem. Whatever is going on seems specific to the share-link hosts as seen from your workers. The same links download fine for us outside Rendi.

Workaround, for anyone else hitting this:

1. In Google Cloud Console, enable the Google Drive API for a project, create an API key and restrict it to the Drive API.
2. Keep the file shared as "Anyone with the link: Viewer". That's still required: the key only identifies the project and doesn't grant access. A private file returns 404.
3. Give Rendi https://www.googleapis.com/drive/v3/files/<FILE_ID>?alt=media&key=<API_KEY> instead of the drive.google.com link.

The key works for files owned by any Google account as long as they're shared publicly; we use one key for two separate Drive accounts. Files stay on Drive: no proxy and no re-upload. As a safety net we still retry UNREACHABLE_INPUT_FILE, but since the switch it hasn't happened once.

It might be worth mentioning this URL form in your docs. Drive share links were the usual pattern until Sep 25, and anyone who has been using them now gets a generic UNREACHABLE_INPUT_FILE with no hint about the cause. If you do fix the share-link hosts on your side, we're happy to test.

[peternaf]

Indeed, Google Drive has changed how they work, which broke drive url downloads
We have upgraded our code to support this change; everything is working again, and you can use Drive URLs without the API key workaround
Thanks for flagging this!