Allow starting of container if foundryvtt.com is down, and release zip has already been downloaded

[cs96and]

🚀 Feature Proposal

foundryvtt.com went down for a few minutes earlier today, at the same time that I was trying to bring my container up. The container failed to authenticate and gave up.

The release zip had already been downloaded from a previous run, and was in the cache, so it could have just carried on with the cached one.

[felddy]

This makes sense.

I think the behavior you are looking for is the same as if FOUNDRY_USERNAME and/or FOUNDRY_PASSWORD are not specified. As documented here: https://github.com/felddy/foundryvtt-docker#required-combinations

So if authentication fails all is not lost. We can still fail forward to the cache.

[ThiefMaster]

Yes, failing forward to the cache would be great. But changing the lookup order to check the cache first would be even better:

I host 7 foundry foundry instances on my server. To avoid asking all my friends for their fvtt account login data, I use my own credentials for the download (but everyone uses their own license key of course).

When updating to a new foundry version, or even just restarting for some other reason (e.g. a server reboot / docker daemon restart), I frequently run into rate limiting (429 error). So pretty much the same problem like when the fvtt site is down.

While failing to the cache would help there, using the cache as the main source first (that's how caches work after all) would avoid spamming multiple logins and requests for a download url in the first place!