Skip to content

Only fetch a release URL if the requested version is not cached - #1409

Closed
alterNERDtive wants to merge 1 commit into
felddy:developfrom
alterNERDtive:push-q
Closed

alterNERDtive wants to merge 1 commit into
felddy:developfrom
alterNERDtive:push-q

Conversation

@alterNERDtive

Copy link
Copy Markdown
Contributor

🗣 Description

We do not have to fetch a release URL if the zip file for the requested Foundry version has already been cached (see #1399).

💭 Motivation and context

Currently, we are always fetching the release URL, no matter if we are actually going to use it or not. With multiple containers starting up at the same time, you immediately run into rate limiting on Foundry’s side.

🧪 Testing

I haven’t tested this yet, just getting the drafts done before I have to head out.

✅ Pre-approval checklist

  • This PR has an informative and human-readable title.
  • Changes are limited to a single goal - eschew scope creep!
  • All relevant type-of-change labels have been added.
  • I have read the CONTRIBUTING document.
  • All relevant repo and/or project documentation has been updated
    to reflect the changes in this PR.
  • Tests have been added and/or modified to cover the changes in this PR.
  • All new and existing tests pass.

✅ Pre-merge checklist

  • Revert dependencies to default branches.
  • Finalize version.

✅ Post-merge checklist

  • Add a tag or create a release.

@felddy

felddy commented Sep 20, 2026

Copy link
Copy Markdown
Owner

Superseded by #1527 (now merged), which builds directly on your analysis and carries your Co-authored-by credit — thank you for the detailed writeup in #1399. The merged version also gates authentication on licensing state, so a first install from a warm shared cache can still fetch its license key.

@felddy felddy closed this Sep 20, 2026
pull Bot pushed a commit to Patlukat/foundryvtt-docker that referenced this pull request Sep 20, 2026
…uest

Every start-up authenticated with foundryvtt.com and fetched a presigned
release URL, even when the requested release zip was already cached and
licensing was settled.  Simultaneous container start-ups sharing a cache
immediately ran into rate limiting (felddy#1399), and a foundryvtt.com outage
could fail a start-up that needed nothing from the account.

Compute the cache paths first, then authenticate only when the release
is missing from the cache or a license still needs to be fetched, and
fetch a release URL only when a download is actually required.  The
FOUNDRY_RELEASE_URL path is unchanged, including its --time-cond
freshness check; release zips are immutable per build, so a cached zip
is trusted as-is.

Based on alterNERDtive's felddy#1409.

Co-authored-by: alterNERDtive <nerd@alternerd.tv>
Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants