Since upgrading from Meteor 2.12 to 2.13 I have been setting numerous errors with a similar format to this in MontiAPM which seem to have to do with socksjs? The names of the functions seem random but all start with _jp:
Anyone have any ideas what is could be about? Should I be concerned?
I noticed there was some mention of a setting in 2.14 to possibly do with socksjs? Is that related:
You can now set DISABLE_SOCKJS_CORS=1 if you want to prevent SockJS from setting CORS headers. Do not set this option if you will have DDP clients from other origins connecting to the DDP server. PR
There does not seem to be any rhyme or reason to when these exceptions are thrown in the app’s lifecycle. Sometimes right away, sometimes after a delay.
I doubt this is CORS-related because that PR is so extremely tiny and simple, and inert if you don’t set that env variable.
In my application this error is still present in the latest version of Meteor 3.3.1 and “spams” my error logs. Is there some progress on this one?
Anyone?
My understanding is when the client disconnects (eg due to upgrade but also due to network problems on their side), this error is generated. Happens on 2.16 too.
When releasing a new version, existing users are more likely to trigger SockJS JSONP fallback upon reconnecting. During deployment, old connections are disconnected, and if a previously issued JSONP response arrives late, the corresponding _jp.xxx callback may have already been cleaned up on the client side, resulting in an “is not a function” error when the script executes.
You can prevent SockJS fallback by setting the environment variable DISABLE_SOCKJS=1 ; browsers or network environments that do not support WebSockets are now rare.
This information was obtained through a query to GPT AI.
