Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash | TypeError: service._emit is not a function #198

Open
1 task
palmtown opened this issue Mar 5, 2024 · 1 comment
Open
1 task

Crash | TypeError: service._emit is not a function #198

palmtown opened this issue Mar 5, 2024 · 1 comment

Comments

@palmtown
Copy link
Contributor

palmtown commented Mar 5, 2024

Hello,

In sporadic featherjs node startups, I am seeing nodes crash with the error as shown below. In short, I traced it to file (/api/node_modules/feathers-sync/lib/core.js line 35, specifically service._emit(event, data, hook);

In short, what is happening is that feathers-sync loads and starts receiving events before the app.mixins function is executed. This functions creates the service._emit function. Given that there is no try/cache or a check to ensure the function exists, feathers simply crashes.

A simply solution would be to check to ensure the function exists before attempting to execute it. I could submit a PR if requested.

Steps to reproduce

  1. Initiate continous events within a cluster that has feathers-sync installed.
  2. Startup a new feathersjs node with feathers-sync integrated
  • Tell us what broke. The more detailed the better.

feathersjs crashed with the following error:

TypeError: service._emit is not a function
at Function. (/api/node_modules/feathers-sync/lib/core.js:38:15)
at Function.emit (node:events:513:28)
at msgFromRedisHandler (/api/node_modules/feathers-sync/lib/adapters/redis.js:22:11)
at PubSub._PubSub_emitPubSubMessage (/api/node_modules/@redis/client/dist/lib/client/pub-sub.js:294:9)
at PubSub.handleMessageReply (/api/node_modules/@redis/client/dist/lib/client/pub-sub.js:233:93)
at Object.onReply (/api/node_modules/@redis/client/dist/lib/client/commands-queue.js:40:87)
at RESP2Decoder.write (/api/node_modules/@redis/client/dist/lib/client/RESP2/decoder.js:119:26)
at RedisCommandsQueue.onReplyChunk (/api/node_modules/@redis/client/dist/lib/client/commands-queue.js:154:72)
at RedisSocket. (/api/node_modules/@redis/client/dist/lib/client/index.js:410:84)
at RedisSocket.emit (node:events:513:28)

Expected behavior

feathersjs should not crash

Actual behavior

feathersjs crashed

@palmtown
Copy link
Contributor Author

palmtown commented Mar 6, 2024

Hello again,

This is a bigger problem than I originally found. Reason being is that this bug has the potential to crash your entire cluster. The way this is possible is that if one of the servers in your cluster starts publishing events for a service that it is not aware of, feathersjs-sync will crash as mentioned in my original issue.

I was able to find this during a blue/green deployment update whereby the new servers with the updated code came online and started publishing events for a new service I implemented. The servers in production received these feathersjs-sync events and crashed as they did not have the new service.

In a blue/green deployment, the new servers are configured to run for X amount of time before they replace the new servers. This is to ensure the new servers are stable before pushing them into production and removing the existing ones.

Therefore, I think this is more support to implement checking to ensure the function exists or a try/cache method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant