Repository navigation
entrypoint: retry SteamCMD app_update + compose ui bind - #6
Conversation
…laky User-reported fresh `docker compose up` failed with: ERROR! Failed to install app '4129620' (Missing configuration) ERROR: SteamCMD exited with 8 Root cause (verified by clean-container A/B): SteamCMD's anonymous app_update is flaky on the FIRST attempt within a container, then succeeds reliably on attempt #2 with no other change. Probably a Steam-side anonymous-license caching quirk that warms up after the first call. Fresh containers always hit attempt #1. Reproduced cleanly: cold attempt #1 FAILs, #2 OK + starts downloading, #3 resumes #2's partial download at ~50-65%. The depots are public anonymous regardless, the credentials are valid, the manifest is present — Steam just returns the cryptic "Missing configuration" on the cold call and accepts the warm one. Existing canary / prod / VPS installs were unaffected because their populated WindowsServer/ trees mean every boot's app_update is a verify-only no-download path that doesn't go through the failing licensing code. So this regression silently shipped to anyone trying a clean `docker compose up` while the live deployments kept working. Fix: retry the heredoc-based app_update up to 3 times, gated on server_files_present (the .exe being on disk after the run). SteamCMD resumes partial downloads across retries, so we don't pay bandwidth twice. Most fresh installs succeed on attempt #2. Switched from `+command` chain to stdin heredoc while we're here — heredoc reads more like the official Windrose dedicated-server FAQ examples that operators paste into interactive SteamCMD for debugging, and is functionally equivalent post-warm-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
seslly
changed the title
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c71e1f1abf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if server_files_present; then | ||
| rc=0 | ||
| break |
There was a problem hiding this comment.
In install_via_steamcmd, this success check promotes any run to success as soon as the server binary exists, but on populated installs that binary already exists before app_update starts (only Saved/ and JSON are stashed). If SteamCMD fails with a non-zero exit due to transient Steam/network issues, this block sets rc=0 and breaks anyway, so the script logs a successful install while silently skipping the update; after game patches this can leave the server on a stale build and cause client version mismatch failures.
Useful? React with 👍 / 👎.
1 participant
fresh-install bootstrap was flaky
User-reported fresh
docker compose upfailed with:ERROR! Failed to install app '4129620' (Missing configuration)
ERROR: SteamCMD exited with 8
Root cause (verified by clean-container A/B): SteamCMD's anonymous app_update is flaky on the FIRST attempt within a container, then succeeds reliably on attempt #2 with no other change. Probably a Steam-side anonymous-license caching quirk that warms up after the first call. Fresh containers always hit attempt #1.
Fix: retry the heredoc-based app_update up to 3 times, gated on server_files_present (the .exe being on disk after the run). SteamCMD resumes partial downloads across retries, so we don't pay bandwidth twice. Most fresh installs succeed on attempt #2.
Switched from
+commandchain to stdin heredoc while we're here — heredoc reads more like the official Windrose dedicated-server FAQ examples that operators paste into interactive SteamCMD for debugging, and is functionally equivalent post-warm-up.