QueryCursor.js is throwing an error on line 144: "TypeError: Cannot assign to read only property 'map' of object '#<QueryCursor>'"

[balonsom]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

QueryCursor.js is throwing an error on line 144:

QueryCursor.prototype.map = function(fn) {

Trying to assign to read only property 'map' of object

TypeError: Cannot assign to read only property 'map' of object '#<QueryCursor>'
    at Object.<anonymous> (/Users/balonsom/Documents/repos/dungeon-master/node_modules/mongoose/lib/cursor/QueryCursor.js:144:27)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1151:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/balonsom/Documents/repos/dungeon-master/node_modules/mongoose/lib/query.js:12:21)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1151:10)

If the current behavior is a bug, please provide the steps to reproduce.

This bug only arose when I upgrade Node.js to v17.5.0. I don't think I can easily provide a script to replicate.

What is the expected behavior?

QueryCursor.js should not throw an error.

What are the versions of Node.js, Mongoose and MongoDB you are using? Note that "latest" is not a version.

Mongoose: 6.2.1
Node.js: 17.5.0
MongoDB: 4.4

[abeledovictor]

Same happening to
mongoose 5.7.7
MongoDB 4.4.12
Node 17.5.0

Temp fix: change your package.json engines line to this:

"engines": { "node": ">=12.0.0 <17.5.0" },

[Uzlopak]

I can reproduce it on node 17.5.

@IslandRhythms You dont need a repoductions script.

Just
nvm install 17.5 && nvm use 17.5 && npm t

And voila you get that issue.

[Uzlopak]

Opened ticket in nodejs bugtracker regarding this

nodejs/node#41926

[sc0rp10n-py]

Is there any alternative for now? I am also using this in my project and its crashed now.

[druv5319]

Having the same issues as well. Any fix?

[sc0rp10n-py]

You can change the node version to v14 and the error gets fixed for now.

[druv5319]

Thanks it worked. My application automatically updated the Node engine to 17.5 and didn't realize what was causing the issue.

[ummerirshadk]

Thanks!! It worked

[hemantvishwakarma]

In local working fine but when i deployed on digital ocean Kubernetes server then showing error. please help....

[ummerirshadk]

@hemantvishwakarma
Please try updating your package.json to node 14. Please refer to the below sample.

"engines": {
    "node": "14.x"
  },

[hemantvishwakarma]

x

i am using this pls check node js - v16.13.1

[ummerirshadk]

@hemantvishwakarma

Add below under "main": "index.js",
"engines": { "node": "14.x" },

[hemantvishwakarma]

@hemantvishwakarma

Add below under "main": "index.js", "engines": { "node": "14.x" },

i did but showing same error

[ummerirshadk]

"engines": { "node": "14.x" },

Try 14.x instead of complete version

[hemantvishwakarma]

"engines": { "node": "14.x" },

Try 14.x instead of complete version

same error

i deployed code on digital ocean Kubernates

[ummerirshadk]

Please check on digital ocean to see if there are other options to specify node version of the image they are using for kubernetes.

[Uzlopak]

This is not a kubernetes specific issue. Kubernetes is a docker orchestrator. So you have to modify your dockerfile to use a working node base image.

Also I would recommend to you to not use odd major versions of node, as they are bleeding edge. Best practice is to use LTS-versions for production, to specifically avoid such issues, and those are node versions with even major-version (12, 14, 16...).

If you use node:latest in your dockerfile, than you are using node 17.5, according to dockerhub. And thats why you have issues.

Best practice for node docker images is to pinpoint exact versions down to patch-version. E.g. use 16.14.0-alpine3.15 instead of 16-alpine. Thus also avoiding caching an old node 16 base image in docker and then wondering why you building on a different machine breaks.

[SLXJS]

I don't know if this is relevant for you, but I had the same problem right at the moment. Up and downgraded my node version. then i realized INSIDE my docker-container there is an other node version. It was defined by my Dockerfile with:
FROM node: 17

So I changed it to:
FROM node: 16

and now it is working!

[hemantvishwakarma]

thank you guys

my old docker file is this -

When i changed this -

NOW WORKING FINE

[SLXJS]

oh lol you already had the answer - I didn't realise while I wrote my comment 😅

[Uzlopak]

@SLXJS

Dont worry. How we Germans say: Doppelt hält besser.

@hemantvishwakarma
You should try to always use latest node LTS version, which is 16.14.0, for security reasons. You should setup a notification on new LTS node versions by using e.g. https://newreleases.io/ and then when you get the information that there is a new LTS-Version, you update your node, run your unit tests, and if they pass, you change your dockerfile to use the newest node LTS-version.

[SLXJS]

@Uzlopak
Wahre Worte! 😌
Grüße aus Karlstadt!

[Lwdthe1]

Thanks @abeledovictor

"node": ">=14.0.0 <17.5.0" worked for me

[sheldonstewart]

guys, I used to have this:

"engines": { "node": ">=12.18.2", "npm": ">=6.14.5" },

and as per the advice here, changed it to:

"engines": { "node": "14.x", "npm": ">=6.14.5" },

and now it works!!!

THANK YOU SO MUCH FOR ALL YOUR HELP, ESPECIALLY @Uzlopak

[lolo-io]

Latest version 17.6.0 of node with the fix (nodejs/node#41931) is out : https://github.com/nodejs/node/releases/tag/v17.6.0
Tested it and the error is gone.

Not available in docker yet as :latest image still points to 1.17.5 but it should be available very soon.
Most users should use the :lts docker tag though as it points to the latest long term support stable release (currently 16.14.0) which never had this error.