Discussing this @ https://discord.gg/amxsMy
Seems like it's back up, but it was a Steam issue -- GS just times out their entire scripts for any issues with GET or POST.
In this case, Steam timed out, and GS waited for the entire timeout duration and vaguely timed out their own script (instead of handling it saying it's a Steam err).
Essentially, GS is taking the blame for Steam bugs due to lacking of a timeout system.
This is also a big issue because if you ping ANY 3rd-party API via GET or POST (any http call), the entire GS script times out instead of properly handling a thrown error.
This was actually reported about a year ago: If staff reads this and wants the ticket with info, let me know and I can surely find it. Simply handling a timeout on HTTP calls would vastly improve GS performance and allow better debugging to http timeouts.
SparkHttp allows for setting a custom timeout but this is not reflected in the documentation
A custom timeout (in milliseconds) can be passed as an additional argument, like:
var httpSender = Spark.getHttp("http://somehost”, 10000);
the default timeout is 30s
When the timeout occurs the httpSender var (in this case) will be null ( you can't catch it like an exception)
That's wonderful for log events -- however, for native events like SteamAuthenticationRequest, we can't add that timeout -- only GS staff can (which could be fixed in 1 line of code).
Here is what happened and how to fix it:
* GS reported as timed out for Authentication via Steam
* Except it wasn't GS that was timed out - it was Steam - because GS doesn't handle HTTP timeouts.
* Since the first event that happens with GS is authentication, GS calls Steam with a ticket -- however, if Steam is down, the HTTP request will timeout. Instead of waiting max ~5 seconds for a reply, GS waits for 30s (the max amount of time for a script to expire). Therefore, the error isn't that Steam timed out (with +info), but that the GS Authentication script timed out with no further info.
* This can be easily resolved by adding a timeout to the HTTP call to Steam's API - say, 5 seconds. After 5 seconds, if no response, then Steam (not GS) timed out - and you can appropriately handle the error (eg, "Steam authentication timed out" instead of "timeout").
Dylan Hunt
Servers went down about 10 minutes ago, flooded with "Timeouts" -- anyone else getting this? I'd assume so, since we didn't do any updates or anything.
* Seems to apply to both our live and preview games.
* Does not seem targeting a certain geo, like last outage a week or 2 ago.