Reporting failure to join Tournament due to a tournament join before hook with custom conditions

#1

Environment:
Client side: Nakama Unity
Server: Nakama 2.6.0

While working with the tournaments API from the client I noticed that joining a tournament does not really return a success or fail. From the documentation it is a call assumed to always succeed.

If we use the before hook to perform checks before allowing the user to join a tournament, and aborting the request with an error if they do not meet some criteria, the lack of reporting back to the client becomes an issue. [In Unity] It prints out an error in the Unity log but the actual async function does not really return anything the client can use to determine if the join was successful.

I can see a couple of ways around this:

  • Instead of before tournament join hook, wrap the join in an RPC and do your join checks there where you can return a custom payload to the client.
  • Attempt to post a 0 score and see if it lets you. (not ideal if the tournament has attempts)

What is the suggested way to determine if the user has successfully joined a tournament?

As a slight tangent from based on the first of the two options I am considering wrapping our entire API in RPCs to give us more control and details over what is returned to the client.

I am curious to hear opinions and a discussion on the ideas and question.

#2

The server absolutely returns an error if joining a tournament fails. You will not need to apply any of your workarounds to make the distinction.

Errors returned from the server should be correctly handled by the Task API, @novabyte might know best how to extract that when using the async/await style keywords. I suspect they’ll be raised as exceptions according to the language reference.

#3

I see, trying to catch an exception out of the async did not really occur to me on that one. I saw the error print and thought thats where it ended.

I’ll have a play around and see how it goes. Thanks :slight_smile:

As a note on this as well, I guess I treated the before hook as more of an “expected behaviour” type mechanism rather than an error catching one.
The point of view being that a user may do something that is correctly prevented by the before hook, when in fact I should have treated the before hook as error / cheat prevention where the UI or another system should have blocked that action to begin with.

#4

Before hooks can be both a prevention and correction mechanism. You can disable the request/feature, or you can adjust the incoming data to something you want to allow. In the ‘disable’ scenario it’s reasonable to consider the client ‘bad’ regardless of reason, since proper clients are not expected to call that resource.

It’s a little hard to provide full flexibility in request/response on top of a strictly defined API but I think we’ve so far found a good balance. Drop back into the forums with any more questions! :+1:

#5

Will do thanks :slight_smile: