You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just spent the last day and a half tearing my hair out trying to figure out why my tests were breaking after upgrading to @typegoose/typegoose v6.
Turns out that the typegoose library stores an internal map of all the models that it has bootstrapped, and when you run getModelForClass if the model already exists in that map, it just returns the first created model.
The problem arises when you use something like MongoMemoryServer to spin up and teardown an in memory Mongo server, as well as a new instance of your nest app for each test block.
The connections to each server are created and dropped just fine, however, that model map is still stuck in a singleton living in the typegoose package. So when it comes around to try and bootstrap models for the second test block, the models from the old server are still in that map, and silently get returned back when getModelForClass is called.
So my services were getting old models, still pinned to the old connection.
I managed to fix this by adding the following to nestjs-typegoose in the onModuleDestroy function
async onModuleDestroy() {
const connection = this.moduleRef.get<any>(this.connectionName);
if (connection) {
await connection.close();
// ==========
for (const modelName of connection.modelNames()) {
connection.deleteModel(modelName);
typegooseData.models.clear();
typegooseData.constructors.clear();
}
// ==========
}
}
I have this living in a temporary fork I created here:
However, this is likely not the final solution. It appears that typegoose is releasing new functions in v6.1 for deleteModel. So once that drops, the above code you likely change to this:
import { deleteModel } from '@typegoose/typegoose'
async onModuleDestroy() {
const connection = this.moduleRef.get<any>(this.connectionName);
if (connection) {
await connection.close();
// ==========
for (const modelName of connection.modelNames()) {
deleteModel(modelName);
}
// ==========
}
}
This new function handles removing the model from mongoose, and the Typegoose model data store.
I just spent the last day and a half tearing my hair out trying to figure out why my tests were breaking after upgrading to @typegoose/typegoose v6.
Turns out that the typegoose library stores an internal map of all the models that it has bootstrapped, and when you run
getModelForClass
if the model already exists in that map, it just returns the first created model.The problem arises when you use something like MongoMemoryServer to spin up and teardown an in memory Mongo server, as well as a new instance of your nest app for each test block.
The connections to each server are created and dropped just fine, however, that model map is still stuck in a singleton living in the typegoose package. So when it comes around to try and bootstrap models for the second test block, the models from the old server are still in that map, and silently get returned back when getModelForClass is called.
So my services were getting old models, still pinned to the old connection.
I managed to fix this by adding the following to nestjs-typegoose in the onModuleDestroy function
I have this living in a temporary fork I created here:
https://github.com/duro/nestjs-typegoose/tree/dist
However, this is likely not the final solution. It appears that typegoose is releasing new functions in v6.1 for
deleteModel
. So once that drops, the above code you likely change to this:This new function handles removing the model from mongoose, and the Typegoose model data store.
See here:
https://github.com/typegoose/typegoose/blob/master/src/typegoose.ts#L206
Just leaving this here for anyone else who runs across this and hopefully the don't loose a day and a half to this.
Once v6.1 of @typegoose/typegoose releases, I'm happy to come back around with a real PR to try and integrate this.
The text was updated successfully, but these errors were encountered: