New Install - Error on all RPC calls

Local Setup
,
1

I am struggling to fix an error we got on a new nakama install. Every (RPC) call results in an error like:

Message sending error: System.Net.WebSockets.WebSocketException (0x80004005): TypeError: Cannot assign to read only property 'lastIndex' at rtBeforeMessageSend (index.js:981:7(147))

or (from another call):

TypeError: Cannot add property hardCap, object is not extensible at handleRPCError (index.js:271:3(27))

Seems some read-only thing but i cannot find any solution. Any suggestions? Tried changing the config at ‘read_only_globals’ and ‘lua_read_only_globals’ (both false) but no difference.
Thanks !

  1. Versions: Nakama 3.11, binary, Linux Ubuntu 20, Azure VM
  2. Server Framework Runtime language: TS/JS

On same server we also have running:

  • Cockroach DB for Nakama
  • Node server
  • NGinx with reverse proxy to serve the Node app

Also:

  • Nakama console works normal.
  • UFW status is inactive
  • telnet to all nakama defined ports connect (using nakama default ports)

:tv: Media:

2

Hello @yomomano, I’m pretty sure this is related to the js_read_only_globals flag, how are you passing it to the server?

3

That was it. Totally overlooked. Thanks !

This setting never caused issues in previous installs with older versions. Did something change in the defaults recently?

4

In v3.11.0 we introduced the js_read_only_globals flag and it defaults to true, meaning that the JS VMs have immutable global state by default. The reason for this change is that Nakama pools the VMs for efficiency, mutating and relying on global state might cause them to behave differently from each other during execution.
We made it the default as mutating global state is generally bad practice, and to prevent users from experiencing the issue above. It can be turned off as it can lead to incompatibility with some libs or in some specific scenarios.
I’d advise to using the default, if possible.

5

I understand. I prefer to keep the defaults of course but this requires refactoring of our existing runtime module (config = runtime.js_entrypoint: index.js). correct ? what’s the best approach for this refactoring?

6

Yes, it would require refactoring. Essentially, scope all variables within your functions unless they’re constant values that are only read. If you’re using some toolchain to transpile imported libraries, it may not be enough as these may introduce some globals to mimick classes in ES5, but I don’t really have suggestions to avoid those scenarios at the moment.