Are we going to get an OAuth2 scope for this?
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?
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.)
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)
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!
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.
That is correct.
Thanks for the feedback! Iāll take this back to the team and see how we can make the docs clearer.
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.