InsertService LoadAsset throws HttpError: Timeout

World // Zero consists of 15+ subplaces:
image

Due to this, we use InsertService to load the shared assets across places (scripts, rigs, models).
Unfortunately InsertService has begun failing at random times recently and this will leave our servers dead because they can never initialize, and this API is not supposed to error.

I can update all the loader scripts in our places to pcall poll on this, but I think this API should handle retrying automatically as this is never the developer’s fault!

5 Likes

This doesn’t seem like a bug to me, web calls can fail at any time, for any service that uses them. That’s something you’re supposed to handle as a developer, and is mentioned on the wiki all the time. It’s not mentioned for LoadAsset specifically, but that seems more like missing documentation.
That said, what’s keeping you from using Packages? The only downside (right now) is that they’re slow to update across places, but they’re definitely more reliable than using InsertService, speaking from experience, switching from InsertService to Packages for our own game.

I have relied on InsertService for a long time. It has always been very fast and very reliable. I would hate to start seeing issues with it.

4 Likes

I think it should be Roblox’s job to handle this sort of case.

Creating a culture of untrustworthy APIs that need to be pcalled because they have the potential to fail randomly is the wrong direction to go down imo. DataStores are a good example of this, many developers struggle to use them and now have to use a lua wrapper “DataStores 2”.

I don’t see a single use case to know if insertservice is failing - this likely means your game is going to be broken along with it. You can also inform the user “this is taking a while” should the API be yielding a long time.

Unfortunately, this is just the reality of using web calls and APIs. They are not designed to be unreliable. But they can be, and eventually will fail, especially at a large scale. Letting the developer explicitly handle what happens when the API fails makes more sense to me, cont.

What if your game lets users insert their own/others content with LoadAsset, and the call fails because the asset has been moderated? You’re probably going to want to display that in a better way than “something went wrong/taking a long time”, and tailor the message.

Suggesting something like AutomaticRetry, for InsertService and the LoadAsset functions specifically, seems like a reasonable feature request to me.

It is my firm belief that Roblox APIs should never error unless given invalid input. It’s a behavior that leads to messy code and even messier games as every developer using these APIs needs to dig through the wiki and see “is this one of the APIs that breaks”.

And in this case, it’s not documented anywhere that this API can break - meaning every developer currently using it is likely at risk. (Unless they are already living under the assumption that roblox APIs will break regardless of documentation, which goes back to the culture issue I mentioned)

So tl;dr I don’t think Roblox should be laying traps for developers, they should handle this logic instead of expecting every dev to re-implement it any place they use the APIs. I want to be able to use InsertService, TeleportService, DataStores, StarterGui:SetCore etc without needing to write lots of fail-retry logic.

1 Like