Mongoose: 5.10.0 -> 5.10.1 Introduces a breaking change (still in 5.10.9)

[jd1378]

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

What is the current behavior? in 5.10.0 mongoose.connection is resolved to instance (?) but in 5.10.1 it resolves to undefined. (using .then())

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

I was using node rate limiter flexible which then after running a yarn upgrade and reruninng project I saw errors. after some time of debugging I pinpointed the issue with downgrading the mongoose version from latest to where rate limiter was still working.

What is the expected behavior? connection.then should resolve to the instance like it was doing so in it's previous versions ?

It's still happening in 5.10.9

[AbdelrahmanHafez]

Welcome @jd1378
The script below demonstrates that mongoose.connect().then() resolves to a mongoose instance, could you modify it to demonstrate the issue you're facing?

9496.js

'use strict';
const mongoose = require('mongoose');
const assert = require('assert');

run().catch(console.error);

async function run () {
  const instance = await mongoose.connect('mongodb://localhost:27017/test', {
    useNewUrlParser: true,
    useUnifiedTopology: true
  });

  assert.ok(instance instanceof mongoose.Mongoose);
  assert.ok(instance);

  console.log(mongoose.version);
}

Output

5.10.9

[jd1378]

connect() seems to be fine, can you try again with .connection.then() ? (I'm busy right now, but I will create a script when I'm free)

[jd1378]

Hi,
Sorry about my last reply, I didn't mean to be rude, thanks for looking into this
It seems that it wasn't returning instance in 5.10.0, but connection.
run the following on both 5.10.0 and 5.10.9 to see what I mean.

'use strict';
const mongoose = require('mongoose');
const assert = require('assert');

run().catch(console.error);

async function run () {
  mongoose.connect('mongodb://localhost:27017/test', {
    useNewUrlParser: true,
    useUnifiedTopology: true
  });
  const conn = await mongoose.connection;

  assert.ok(conn instanceof mongoose.Connection);
  assert.ok(conn);

  console.log(mongoose.version);
}

[AbdelrahmanHafez]

@jd1378

Sorry about my last reply, I didn't mean to be rude, thanks for looking into this

Stating that you're busy isn't rude in any way.
Also, happy to help. I put in a PR to fix the issue you're facing.

[vkarpov15]

Thanks for pointing this out @jd1378 . However, please note that this behavior will change in v6.0, please see #8810 for notes. I'd recommend you do this instead:

  await mongoose.connect('mongodb://localhost:27017/test', {
    useNewUrlParser: true,
    useUnifiedTopology: true
  });
  const conn = mongoose.connection;

[jd1378]

Thanks for letting me know.
It's not really straightforward for many applications to just do that, I know for sure that it will be a breaking change to my project at least due to the way it's written

[vkarpov15]

Another alternative is to just do const conn = mongoose.connection; without the await. There's no real need to await on mongoose.connection, you get the same object back either way.

[vkarpov15]

Is https://github.com/animir/node-rate-limiter-flexible the project that you're concerned about or is there another one?

[jd1378]

yeah thats the one
the connection is not awaited before passing it to the rate limiter in my project

[jd1378]

this is the line I'm concerned about
(which is the reason of this issue also)

[vkarpov15]

Based on my reading of the code you linked to, there's no reason why you shouldn't be able to do

  await mongoose.connect('mongodb://localhost:27017/test', {
    useNewUrlParser: true,
    useUnifiedTopology: true
  });
  const conn = mongoose.connection;

And pass conn into RateLimiterMongo. https://github.com/animir/node-rate-limiter-flexible/blob/06b3d07478dee9c608c5aa687e64a1eea673f332/lib/RateLimiterMongo.js#L35 handles the case when conn isn't a promise.

[jd1378]

yes it does handle when it isn't a promise, but the thing is I need a refactor before I can await the mongoose connection before giving it to rate limiter.
Overall It's not like it's impossible, just that it takes more time and effort to get it working again later (so yeah, It's okay 👍)