Some in-studio calls to SetAsync are raising HTTP 403

Reproduction Steps
Currently, there is no way to do this for small scale or localized tests as far as I can tell. I have only noticed this issue when attempting to modify player saves in Creatures of Sonaria - I do not have access to any other large scale games where I can test this. I will include which keys raise this error in the private message, since ideally these can help nail down the problem as they do consistently raise this error.

Unfortunately, the steps to reproduce this assuming it occurs 100% of the time are also worse than useless:
1: Load player data via GlobalDataStore:GetAsync
2: (Optional) Modify this data in any capacity.
3: Attempt to save player data via GlobalDataStore:SetAsync. At seemingly random, the call for this specific data store key may or may not raise HTTP 403.

Although likely unrelated, for the sake of completeness:

  • CPU: Intel(R) Core™ i9-10900K CPU @ 3.70GHz
  • Memory: 32GB DDR4 @ 2666MHz
  • GPU: NVIDIA GeForce RTX 3070 Ti

Expected Behavior
When calling SetAsync, I expect this issue to not arise unless I have not been logged in, or have lost permission to modify the experience. That is, some case comes up where I genuinely do not have access to the save data. I also expect all data store calls to raise HTTP 403, not these specific Set calls to specific keys.

Actual Behavior
Using this test script in studio (note the other player’s user ID has been omitted with ######## for privacy)…

local DataStoreService = game:GetService("DataStoreService")
local DataStore = DataStoreService:GetDataStore("PlayerData")

print("Getting Eti's data.")
local EtiData = DataStore:GetAsync("PlayerLive_18406183")

print("Getting Zero's data.")
local ZeroData = DataStore:GetAsync("PlayerLive_########") -- This is a random player who happens to have this issue, and a friend of mine.

task.wait(1)

print("Saving Eti's data...")
DataStore:SetAsync("PlayerLive_18406183", EtiData) -- This should work fine, following the patterns.
print("Successfully saved Eti's data.")

print("Saving Zero's data...")
DataStore:SetAsync("PlayerLive_########", ZeroData) -- This should error, following the patterns I've noticed.
print("Successfully saved Zero's data.")

I get the following result:

Error

It is worth it to note again that this issue does not occur to all keys, and never occurs in the live game. Instead, it seems to occur to a select set of keys in studio that follow no pattern in particular. When I attempt to modify someone’s data, it either does or doesn’t raise HTTP 403. If it does, it will consistently do so regardless of the circumstances. Keys that error will always error no matter the time or context.

Some patterns I’ve attempted to verify without success (that is, it’s still inconsistent across both groups) are:

  • Size of the player’s save data, including with and without strings >200K chars (if I recall, these cause problems? Please let me know)
  • Specific user IDs and their account age.
  • Whether or not the player is online (website).
  • Studio data store settings (all access is enabled to API services within studio.)

Workaround
The only workaround to this issue is to schedule a time to join the game with a player and use the in-game developer console (F9) to modify their save data. This is extremely inconvenient for both me and the player in question.

Issue Area: Studio
Issue Type: Other
Impact: High
Frequency: Sometimes
Date First Experienced: 2021-09-27 00:09:00 (-05:00)
Date Last Experienced: 2021-10-15 00:10:00 (-05:00)
A private message is associated with this bug report

1 Like

@EtiTheSpirit Would you be able to upload your Studio logs?

Yes, I will get them uploaded to the private message in a few minutes unless you need me to put them somewhere else.

Edit: Looks like I also had to invite you to the message, so that’s done.

Thanks for the report! We’ve filed a ticket to our internal database and we’ll follow up when we have an update for you.

3 Likes

This issue has been resolved after some work with and from the engineers involved with the issue, and is no longer occurring, tested as of 9:32 AM CDT on 22 October 2021.

This topic was automatically closed after 7 days. New replies are no longer allowed.