nk.storageDelete fails when no collection userId is provided


I may be missing something obvious here:

  • We are executing the following server side code in the match loop handler, which fails unless the collection user ID is set to “00000000-0000-0000-0000-000000000000”. The collections are created in the match loop by a similar method (storageWrite).
          collection: "island-user-instances_0_1_B_Wood_Set",
          key: "-6_0_-162",

Isn’t the server authorized to write/delete collections regardless of their ownership?

The error in question that crashes the server:

{"level":"warn","ts":"2021-07-21T20:47:36.825Z","caller":"server/match_handler.go:287","msg":"Stopping match after error from match_loop execution","mid":"1508b848-713e-4879-962a-51057a8d5d68","tick":351,"error":"GoError: failed to remove storage: Storage delete rejected - not found, version check failed, or permission denied. at github.com/heroiclabs/nakama/v3/server.(*runtimeJavascriptNakamaModule).storageDelete.func1 (native)"}

Update: using SQL queries to handle the above deletion works as expected regardless the ownership status.

@Leonidas this is by design, the userId must be set to the owner of the collection as the key/collection pair is not unique.

I can see from the image that the owner of this collection is not the system user so it should be set accordingly. I believe in this case the nk.storageDelete call was failing because it did not find anything to delete.

We’ll improve the storageDelete input checks in a future release to make it clear that userId is not optional.

1 Like

Thanks @sesposito, we were able to use SQL queries to handle our logic so this isn’t a showstopper for us.