[Beta] Open Cloud Engine API for Executing Luau

[NinjaFurfante07 (iKingNinja)]

Are we going to get an OAuth2 scope for this?

[RuizuKun_Dev (Kitsune)]

@DevelopmentDeadline

You poll for the operation status, and upon completion, receive the script’s return values and logs.

would i be able to use websocket for this?

if no will this ever support websocket?

@DevelopmentDeadline

Access to some cloud service APIs (like DataStores, HttpService, etc.) is disabled to prevent accidental overwriting of production data.

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

[unmiss (Jack)]

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.)

@DevelopmentDeadline

[NotAstrain]

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)

[Dekkonot]

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!

[Dekkonot]

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.

[icemountainrbx]

@Dekkonot

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?

That is correct.

@Dekkonot

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.

Thanks for the feedback! I’ll take this back to the team and see how we can make the docs clearer.

[icemountainrbx]

@Dekkonot

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.

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.

[Boegie19]

@DevelopmentDeadline

@ChasingSpace

Do you ever see the possibility of a fake player which can perform certain tasks (e.g. click UI buttons, interact with ProximityPrompts, etc.)?

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.

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.

[27_0Glocks (jayy)]

How will rate limiting work on this endpoint, and will any future saves be recorded as individual versions in the place’s history?

[DevelopmentDeadline]

@DevelopmentDeadline

Script.Source is not accessible (we know how important this is to testing workflows, so we’re actively working on a fix here) Script.Source is now accessible!

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.

[PureBigMadBoatMan]

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.

[kalrnlo (witchiest)]

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.

[icemountainrbx]

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.

[icemountainrbx]

The engine API restrictions have been lifted.

For historical reference, this was the list of APIs that were blocked (which are now accessible from task scripts):

  * AssetService:CreatePlaceAsync()
  * AssetService:SavePlaceAsync()
  * DataStoreService:GetDataStore()
  * DataStoreService:GetGlobalDataStore()
  * DataStoreService:GetOrderedDataStore()
  * MemoryStoreService:GetHashMap()
  * MemoryStoreService:GetQueue()
  * MemoryStoreService:GetSortedMap()
  * Players:BanAsync()
  * Players:UnbanAsync()
  * Players:GetBanHistoryAsync()
  * HttpService:GetAsync()
  * HttpService:PostAsync()
  * HttpService:RequestAsync()
  * MessagingService:PublishAsync()
  * MessagingService:SubscribeAsync()
  * DataModel:SavePlace()

@Noble_Draconian @Kampfkarren @pyxfluff @RuizuKun_Dev @ChipioIndustries @ChasingSpace

[pyxfluff (Pyx)]

Thank you, this makes the feature way better now.

Will we see a way to trigger RbxScriptSignals like MouseButton1Click, PlayerAdded, etc anytime soon? I’d love to be able to emulate clicks

[DevelopmentDeadline]

We’re thinking about how best to support client testing. What you’re describing sounds a little like connecting an emulated player to the server the task is running in. Would love to learn a bit more.

[pyxfluff (Pyx)]

In this case I’m mostly just interested in emulating player clicks and common actions they’d take for better testing workflows (for example i can setup a button, click it, then check the text and if it doesn’t change to an expected value we can expect an error happened). Full client emulations would be cool for testing full on games (like moving the character to a position) but my use case is more for testing something like a shop UI ingame.