Dependency on server module does not work

Runtime Framework
1

In our plugin code we’re checking an error returned from group creation. We need to import Nakama server module to be able to inspect if an error is of type that is expected.

import (
   "github.com/heroiclabs/nakama/v3/server"
)

func CreateTeam(ctx context.Context,
	logger runtime.Logger,
	db *sql.DB,
	nk runtime.NakamaModule,
	payload string) (string, error) {

  // ...
  group, err := nk.createGroup(ctx, ...)

  if errors.Is(err, server.ErrGroupNameInUse) {
    // Group already exists (this is sometimes expected)
    // Handle, e.g. try a different name
  } else {
    // Unexpected error
    return "", err
  }

  // ...
}

In our Docker compose file we have

  nakama:
    container_name: nakama
    image: heroiclabs/nakama:3.5.0

That is, we’re using Nakama server version 3.5.0 so in our plugin’s go.mod we’ve put

require (
  ...
  github.com/heroiclabs/nakama/v3 v3.5.0
  ...
)

However, when starting up the server we get

{"level":"error","ts":"2021-09-27T07:12:50.027Z","caller":"server/runtime_go.go:2492","msg":"Could not open Go module","path":"/nakama/data/modules/plugin_code.so","error":"plugin.Open(\"/nakama/data/modules/plugin_code\"): plugin was built with a different version of package github.com/heroiclabs/nakama/v3/apigrpc"}

We would have expected this to work since the plugin is referring to the version of the server that the plugin is executed in. Are we doing something wrong or is there a limitation that in the plugin we cannot refer to public variables of the server module?

2

@ari-skunkworksgames This will not work because of the way Go packages are managed through the dependency resolver. Unfortunately you cannot import the Nakama server Go package directly which is why we manage all the function signatures and interfaces as part of the “nakama-common” Go package.

It’s not clear to me what you wanted to achieve above. Is it to get access to the error type ErrGroupNameInUse? If so please open an issue and we’ll move the type to the common Go package.

3

Thank you for your quick reply.

We want to be able to distinguish between the different errors we get when calling nk.createGroup(...) so that we can handle them differently. We know that technically we could check the human readable error message (e.g. “group name in use”) but we’d much rather do the checking in a “type safe” way. Checking human readable error messages would break as soon as someone changed the error message e.g. for correcting a typo.

If we understand you correctly you’re suggesting opening a ticket for moving the error types to nakama-common module. This would be a suitable solution for us and it sounds like the right thing to do anyways: In our opinion the error types should be part of the server’s public API that can be utilized by the plugin code. We opened a ticket for this: Error types should be part of nakama-common · Issue #691 · heroiclabs/nakama · GitHub