Insufficient description of possible errors for runtime methods

Hi again! Now I’m working with the go runtime and I lose a lot of time time because I have no the list of possible errors for some methods. Let’s look, for example, at nk.GroupsGetId.

In the documentation (Heroic Labs Documentation | Function Reference) we have the description of returned values:

Name Description
getGroups *api.Group An array of groups with their fields. - That’s ok
error error An optional error value if an error occurred. - I can not identify possible errors

I can’t know what happens if we pass the invalid groupID to the method: the method will return an empty groups list without of any errors, or it will return some error.

If the method will return the InvalidGroupID error I need to know how to identify this error, because there are possible different errors and different errors require different handling. For example, it can be returned some error while try to read the data from the database which is on a different node. So in the case of an invalid groupID I need to return the InvalidArgument status, and in the case of a data read error I need to log this error and return InternalError status to the client

Of course, I can make a test request with invalid groupID and to see that the method returns “each group id must be a valid id string”, but I lose a lot of time to learn the behavour of some methods.

Hello @Andrey,

Ideally these errors should to exposed in the runtime interfaces, we’ve done this for a few functions but unfortunately exposing and documenting all errors is a non trivial amount of work.

I’d argue that this is also a limitation of how Go works, there’s no way of exposing to the caller what errors it should expect, and even if we expose constant values for these errors in the runtime interface - so that the caller can check against them - we’ve not followed a convention on, let’s say, always returning a consistent argument error, if that’s the case.

The Go language has been introducing better utility functions around error handling in more recent versions, so this is also a case of having written Nakama before some of these were available.

We strive to make the development experience better, so my suggestion would be to open an issue on Github that we can track, and for now, you can go through the source on our OSS repo (be sure to select the tag with the version you’re using), and look for any returned errors you want to handle explicitly by comparing the returned error strings.

Hope this helps.

1 Like

Ok, thank you, I got it.

Just to follow up on this, we’ll work on improving the docs to list the runtime interface errors that a function can return.

Feel free to open issues on the OSS repository if you think an error that should be defined in the interface is missing for a given function.


1 Like