Currently, if you try uploading a large rbxlx place file with the upload API (https://data.roblox.com/Data/Upload.ashx?assetid={}), the request will either time out or result in an internal server error.
Reproduction steps:
Take a large rbxlx place file (89MB or higher), and try uploading it to the API with tools like remodel or rojo. You should either get an internal server error, or a “timed out” error.
Do the same thing as above, but use a smaller (12MB or so) rbxlx file. Note that the upload is successful.
I’m not entirely sure if the size limit applies to binary (rbxl) files as well, as I have not tested it with binary.
I came across this bug when I was trying to set up automated deployments on my github repository and saw this error logged in my workflow output:
I was able to upload the large place mentioned above through Roblox Studio. Unfortunately we don’t officially support Rojo or other open source products, so I would take this up with their respective owners.
Here’s a slight rant. While this response doesn’t necessarily warrant it, I think this is an overall issue within Roblox–and this response reflects the state that Roblox is in right now.
I respectfully recognize that Roblox is within it’s right to not support these end points–and this case, I can see why Roblox may not support this end point (undocumented end point). However, the fact that developers have to resort to using undocumented end points feels bad, I think this points to a bigger issue within Roblox, which is the fact that we have no support for any sort of tooling or automation around Roblox development. Does Roblox ever plan to support this sort of development tooling? As far as I can tell, it’s not on the roadmap.
I believe that this sort of cultural attitude around tooling and external tools is unhealthy for Roblox to have as a company. Unfortunately, this sort of reply we get consistently around rojo and other tools feels actively dis-empowering. It’s like we’re being made less effective.
I wish that Roblox would support this sort of tooling and take ownership of this sort of API. The fact these tools exist (for example, tooling to make Git work for Roblox) in my opinion feels like a failure of Roblox as a company to consider its advance users as a valid user group. I don’t think it’s unreasonable to pragmatically upload an asset when games advance users manage have millions of users per a month.
It feels disrespectful to consistently be told Roblox doesn’t support any sort of tooling like this. It’s especially grating that Roblox itself is using this sort of tooling in its development of its platform, but that we have no access to this sort of tooling ourself. For example, FileSyncService exists, but is only internal. And then Roblox refuses to support rojo. This seems ridiculous to me.
So while it does feel reasonable for Roblox to not support these undocumented end points, from a higher level it feels really bad from my perspective, to hear this sort of feedback from Roblox. I know this isn’t something you, @iamtamchu, may specifically have control over, but I think it’s important to articulate why this sort of response is disappointing.
The issue here is with API, not tooling. Even if you don’t ‘officially support’ tooling like Rojo, it’s still good practise to have a robust API to allow developers to design whatever workflow works best.
Slightly off topic here but Rojo is just by the majority of the platform’s top games, including many record holding and innovative games; and to top it, a few teams at Roblox use Rojo and similar tooling.
It seems like a feature request for an officially supported and documented endpoint for place uploads is more appropriate than this bug report, since this is regarding an internal endpoint that is by definition subject to unpredictable breaking changes. It is unwarranted to look into this without the use-cases and justification posed by a feature request since this endpoint is only meant to be used in very specific ways.
It’s not that this issue isn’t valid because third party tooling is not supported, it’s just that supporting third-party use of an internal, unsupported endpoint is a hindrance to platform development and is entirely out of scope.
Thank you for reporting this issue! Our backend is returning HTTP 500 errors because it is unable to handle large places files. Ideally it would send back a 4xx HTTP response code and indicate the maximum place file size is. We will either fix this endpoint or provide a replacement endpoint with better error codes.
@Quenty You bring up some good points about the larger issues around external tooling & application support. I would suggest posting this to Platform Feedback because this warrants a larger discussion outside the context of this specific bug.
