Cache remote build map, fetch in registry refresh #3624
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HebaruSan
added
Enhancement
techman83
approved these changes
Aug 12, 2022
| Log.Debug("Getting cached build map"); | ||
| return TrySetBuildMap(File.ReadAllText(cachedBuildMapPath)); | ||
| } | ||
| catch (Exception e) |
There was a problem hiding this comment.
Are we doing anything with this exception we're catching? We're getting a few notes about it.
There was a problem hiding this comment.
No; unlike the other TrySet*BuildMap functions, we don't want to print a warning for this one because we expect it to be missing the first time. I've removed this variable.
HebaruSan
force-pushed
the
fix/build-map-caching
branch
from
9736606
to
1e3c574
Compare
|
As for tests, I don't know how this could be tested, since it depends on writing to and reading from |
|
For fun I took the latest build for a spin in my Debian and Fedora VMs with their network devices disabled, and the commands that don't need network access all worked fine. 🎉 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problems
My network has been a bit unreliable lately, and I've found that during periods of downtime, not only can I not download mods, but even commands like
ckan instance listsimply hang. (First noticed while working on the Electron UI project previewed in the comments of #2848, which just wraps aroundCKAN.dllwithout additional C# code being run.)Cause
When CKAN starts, it loads all the game instances pretty early. To do this, it first has to load the known game versions so it can check each instance's version. Currently we always use the remote build map for this, via an HTTPS request to GitHub. If the network isn't working, it just sits there waiting for timeout.
This isn't a great model. As pointed out in #2108, CKAN should refrain from creating network connections without the user's awareness, especially if it isn't necessary. Furthermore, we already have an embedded build map compiled into CKAN that we essentially never use, because the remote build map is always retrieved first.
An additional quirk is that the command line parameters are handled after all this, so even if you pass
--debug, thelog.Debugoutput of these steps is never printed.Changes
config.json). If found, we use it, otherwise we fall back to the embedded build map. This eliminates the network call at startup and would allow commands likeckan instance listto complete while offline.ckan updateand GUI's Refresh button is updated to fetch the remote build map and save a cached copy for future startups, since this represents a time when the user has authorized network activity.--debugor--verboseand set the log level if found. This way these arguments can be used to see activity before the full parsing happens, including the build map's initialization.