Wow so happy to see this. IF there is any feedback on what you did or how we can make it better, we would love to know! Feel free to respond here or DM me.
3 Likes
We are looking at this on an API by API basis. Please let us know what you need, that isn’t available right now! We’re starting with script.Source in the very-near future.
Can you let us know your use case for increasing over 30 seconds? We plan to increase this, but understanding what people use this for is important in making sure we do this in a sensible way.
We know we need to support passing data into this API better. Today you need to template a string into your script. We’re looking at the best way to support here. Arguments will likely be part of the story but we may need other mechanisms for passing in larger amounts of data.
This is a huge topic! No immediate plans but we are thinking about what the story should be for client testing. This will take a while to figure out, so any feedback about your use cases are helpful here.
4 Likes
Thanks for the candid feedback here - and for taking the time to type up your use case in more detail!
The background here is that we are being cautious. I totally get why it might feel like we’re being too cautious. Given we were launching a whole new way of interacting with the platform, some of the things we worried about included:
- Open Cloud has distinct scopes for some of the same things that Lua APIs can access. Would users expect the DataStoreService Lua API to work, even though the DataStoreService Open Cloud scope is not present on the API key?
- Open Cloud is premised on granular access to resource, whereas scripts in the engine enjoy broad access.
Ultimately - we want to give you the ability to call these APIs from cloud Luau execution, we just wanted to take a bit more time to plan how to support this. Feedback that this restriction is blocking a real + pressing use case for you is very useful. We’ll discuss more internally and get back to you when we know the next steps.
6 Likes
I get the reasoning and appreciate it, though it reminds me of how you already can do this… sort of. If you have access to publish to the universe (or even directly edit in Studio), you already can manipulate data stores without the OpenCloud permissions.
However, I won’t argue too much on this point because I think it’s worth exploring potential ways to secure this rather than blowing it wide open just because of something else. Two wrongs don’t make a right.
Other than those APIs, I think there is specific value in allowing AssetService:CreatePlaceAsync() since you cannot perform this task with OpenCloud as it is now. The endpoint only exists for user authentication.
This isn’t very thorough but should give you an idea as to what we’d like to see:
We have a separate tutorial place in our experience which is a cut down version of our main game. Sometimes, when we ship updates, the tutorial place can break because of a dependency on something only available in the main game.
Generally, we would like to quickly test if a player is able to join, load their data, interact with the first quest giver, and accept the quest. This is usually a strong indicator that the rest of the tutorial will continue on smoothly. We might add a few more checks where possible and necessary.
Specifically we would need:
- A Player object
- Ability to trigger ProximityPrompts
- Ability to send inputs
Our experience has cases like this but it is very very bad when the tutorial breaks due to something stupid. Not being able to automate this process slows us down since we have to make sure every individual thing works.
Maybe a more specific question is, when does the 30 second timer begin? I was originally thinking that it might include load time and our main place is quite large, so I wanted a bit longer to accommodate… however, it doesn’t make sense to include load time.
I see this as parallel with serverless functions that have a time limit. Sometimes, you wish you had just a bit more head room for certain things. I can see growing interest in higher limits when certain APIs are allowed, such as updating the place.
I don’t have an immediate use case yet as I’ve been locked in on completely unrelated work and haven’t been able to test this out yet. I’ve got the itch to completely rip and tear through our stuff and find use cases.
At minimum, is there a way to gracefully end tasks that go over their limit (e.g. game:BindToClose)?
1 Like
You’ve got 10 requests / player / minute as a soft limit and a few more requests from the 60 buffer that Roblox gives you.
I definitively think there is a way to migrate in your case. Alternatively, you could also have a piece of code that starts a bulk migration if it detects the current reserved server owner is you or one of your devs.
In conclusion, I’d suggest you migrate. Cheers!
2 Likes
Hey, so firstly this feature is AMAZING! Never thought Roblox would ever expand capabilities to this extent.
Now my main question is, could we get persistent task servers from this? essentially having a never ending task? I suggested this a LONG time ago . This would allow us to program matchmaking for instance by having a sort of “brain” server to manage everything, along with caching of datastores certain datastores. Now that we have MessagingService and MemoryStoreService, we can already enable communication between servers, but logic is still a bit difficult to do for peer to peer instead of peer to main server. I understand the matchmaking system was announced, however I’m sure some games will still need to implement their own type of system because of how their own games are designed.
In my use case for a persistent task server is I have factions and a TON of territory on my space game, and each server has to load ALL factions data that exist on the territory (so players can see name of ownership, etc), and the sheer number of factions loaded could exceed a thousand for example, by having a server manage updating the faction data (because it could be updated by many servers at once, datastores may conflict or have problems even with UpdateAsync), it would manage the MemoryStoreService to keep a cache of the latest data, then in the background saving changes to datastore without conflicts since it can merge changes. (Example would be multiple servers adding new members to the faction at the same time, the faction data would have a list of members)
Another use case is handling reserve servers and teleports, right now each sector of my map has a reserve key associated with it, so if a player enters that territory, they’re teleported to that server. The problem is if that server is full, i need a system to automatically expand to another server, but it can’t be a regular server since the reserve keys are what tells the server what sector data to load. By having the task server, it’d allow me “ask” it where to teleport, and based on the players relation (faction, wars, etc) it could then decide to open up a new server, currently with just MemoryStoreService, this is not very easy to handle.
I’m sure there are many more use cases for a persistent task, it is already a running place, just with a time limit, so by allowing 1 or even a few to be persistent per experience would open up countless possibilities, while also reducing the need for externally hosted web servers.
2 Likes
Are we going to get an OAuth2 scope for this?
1 Like
would i be able to use websocket for this?
if no will this ever support websocket?
Need a way to determine running in cloud environment and a way to determine if a service is available in cloud environment
The script runs in Server context only right?
cc @DevelopmentDeadline , @PureBigMadBoatMan, @icemountainrbx
2 Likes
I’m using this API to bootstrap TestEZ tests in my game. How do I determine if I’m currently in a testing environment? For example, I want to use a mock datastore in my tests instead of DataStoreService, because it’s not supported.
RunService won’t provide any useful information (IsStudio() returns false, but that’s probably expected.)
1 Like
This might be janky, but I just put this at the top of the source I was sending:
workspace:SetAttribute("IS_AUTO_TEST_ENVIRONMENT", true)
3 Likes
I’m finding the docs rather confusing; if not for the example scripts provided, I’m not sure I’d actually know how to use this.
I can’t really give a specific example of what’s wrong with them beyond saying that it’s really not clear what the actual format of requests are and what the results are. I… assume that LuauExecutionSessionTask is the request format and then it’s reused for the result, but with the fields that are marked as “Output Only” included? If this is the case, why would it not be documented as two distinct structs? It feels like an implementation detail being leaked to users.
Some clarification would be helpful!
2 Likes
Something I’ve noticed is that the LuauExecutionSessionTaskLog seems to not differentiate between the types of output that can exist.
You can run code like this, which should put 4 different types of text in the Output:
local TestService = game:GetService("TestService")
TestService:Message("test blue")
warn("test yellow")
TestService:Error("test red")
print("test normal")
However, they’re all indistinguishable from one another when retrieved with the OpenCloud Luau Execution Task Logs endpoint (quite a mouthful). Is this something that can change?
It’d be cool if I could e.g. omit warnings from the output.
1 Like
That is correct.
Thanks for the feedback! I’ll take this back to the team and see how we can make the docs clearer.
2 Likes
Thanks for reporting this. Having the MessageType in the log output definitely makes a lot of sense. We are going to work on adding it.
2 Likes
I would use this mostly for E2E testing of my scripts.
I would like this to have a way to recorded tests like most E2E testing frameworks. This is to speed up the process and make it easier to start E2E testing for everyone. Since your first E2E tests could just be recordings without any edits.
I would use player object it for the following reasons and test ceases:
1: It would detect if the game is fully broken and in an unplayable state.
2: I would use end-to-end tests on my player interactions. From start to finish
Examples would be team selectors. I can test if the GUI works as expected, but I can’t test if it actually changed the player’s team without mocking the player
Other examples would be car spawners, entering and leaving the car, Tool givers, character customization and so on. Aka tests that all interactions that are in the game are working as intended and are functional.
1 Like
How will rate limiting work on this endpoint, and will any future saves be recorded as individual versions in the place’s history?
1 Like
Good news, we’ve just enabled access to the Source property of scripts via open cloud Luau execution.
We’re working to update the API docs site to make clear that script.Source is only accessible from the Open Cloud Luau Execution API and Plugins.
For anyone who is curious what this means - Roblox’s automated Lua test framework Jest-Roblox now supports module mocking via the script.Source property. One this change makes it into the community fork jsdotlua/jest-lua you will be able to use Jest via the Open Cloud Luau Execution API.
4 Likes
We’ve since fixed this, though we’re still aware of some known issues with the docs that we’re still working on fixing. Thanks for calling this out.
2 Likes
Could we see Player as a creatable instance for testing? Or at least have PlayerAdded fired with a mock player?
It’d be useful for being able to test so much more, like Product purchases, badges, character loading like applying scaling effects to make all characters have a consistent scale GitHub - EgoMoose/rbx-rthro-scaler: A Roblox module that adjusts the height of avatars and retains their proportions., ect.
1 Like
Hi everyone,
Thank you for trying out the beta release of the OpenCloud API for Luau Execution.
As you might know, when running a script inside a Luau Execution task, some engine APIs are blocked. We implemented this to prevent accidental modification of production data.
We are now planning to remove this restriction, so that all engine APIs available to game scripts can be used from Luau Execution task scripts.
To ensure that this change does not happen without your knowledge, we will be removing the universe.place.luau-execution-session:write scope from all API keys that have been used to call the OpenCloud API for Luau Execution, unless you explicitly opt-out. Removal of said scope from a key will prevent it from creating new tasks.
We have already sent out DMs regarding this, but in case you didn’t get one, feel free to DM me if you wish to opt-out.
If you choose to opt-out, then any Luau Execution Session Tasks created by any existing API keys that you own will gain access to previously blocked engine APIs. These engine APIs can access and modify data stored in the cloud. (See the documentation for the complete list of such APIs.)
We will begin removing the scope from API keys tomorrow November 20th at 1pm PST. The engine API restrictions will be lifted shortly after.
2 Likes