-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Curseforge API Issues should not be fatal if pack is already installed #3159
Comments
I got the same problem. I am not able to start my server anymore. |
Please provide your container config but be sure to hide the API key. |
I am not asking for support with the API key issue, just that it should not exit the pod if there is an API issue and the pack is already installed. It is really not just if there is a 403, but for any reason (similar to #2175). If a pack has already been initially installed, the container should not break on restart for any reason related to networking issues. |
I'm asking because I want to know if you're specifying a specific modpack version or not. |
I am. |
This enhancement request is basically a duplicate of #2175. |
I do agree they are essentially the root cause/fix. That is specifically saying "Internet connection required" though. It should be reworded/renamed to something like "containers should not fail to restart if installed and there are any network issues". Since in this case, it is because of a bad response to Curseforge not a lack of Internet. |
Right. The point is that there is a very small, but non-zero number of API calls needed to reconcile the requested modpack identifier/version and confirm it's the one previously installed. I usually prefer not to change people's issue titles, but looking again it does seem like it could benefit from improved wording. Edit Their issue was encountering network requirements even before steps like cross checking CurseForge modpacks. So, yes, vaguely similar root causes, but distinct enough otherwise. |
You could just write a simple file out say what the last "installed" pack was. Then if the old pack and the new pack match then
|
It does do that. Look at the file
|
I do not see why you would need network calls then. If |
With debugs looks like it needs 3 API calls (but one was cached):
Just noting if someone wants to help improve the code, it's located in https://github.com/itzg/mc-image-helper/tree/master/src/main/java/me/itzg/helpers/curseforge |
@dominik-tietz please open a separate issue and provide container config and logs. |
I wrote out a long comment related to the underlying 403 issue but then deleted it when I realized I had my |
@Djent- unescaped dollar signs get pre-processed by docker as variable placeholders so the behavior is before is before and beyond the control of the image tooling. I'm also at the mercy of whatever API key format CurseForge chooses -- they might someday decide not to use the prefix with dollar signs in it. With that said, they've stuck to that format for a while now so I guess I could have the code inspect for that and print a warning about the unexpected format. |
Enhancement Type
Improve an existing feature
Describe the enhancement
If an
AUTO_CURSEFORGE
pack is already install, encountering Curseforge API issues (403 /Access to https://api.curseforge.com is forbidden or rate-limit has been exceeded
) should not block startup of the Minecraft server.I have had a pack installed for a bit over a week now. Restarted multiple times, everything has been fine. This morning, I scaled down the server to update a server config and now when I start it up I get:
I have already tested my API key and everything locally and it appears to work. I think it is just Cloudflare temporarily flagging my IP or something. But still, a simple restart should not take down the whole server if the startup cannot communicate with Curseforge. The pack is already installed. Throw a warning it could not check for updates or something and let it continue.
The text was updated successfully, but these errors were encountered: