zod-prisma keeps getting stuck at the generation step - prisma

I just installed zod-prisma to try it out, but so far nothing is working.
I attempted to run it on two separate projects, one has a small prisma and the other has a relatively large one.
Both didn't work, and remained stuck.
I can't share the schemas unfortunately. So, any ideas what could the problem be?
I also enabled strict in tsconfig, still the same.
prisma : 3.6.0
#prisma/client : 3.6.0
Current platform : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/#prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine : migration-engine-cli dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/#prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/#prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary : prisma-fmt dc520b92b1ebb2d28dc3161f9f82e875bd35d727 (at node_modules/#prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash : dc520b92b1ebb2d28dc3161f9f82e875bd35d727
Studio : 0.440.0
typescript": "^4.5.2"
"zod-prisma": "^0.5.4"
{
"compilerOptions": {
"target": "es2018",
"module": "commonjs",
"lib": ["es2018", "esnext.asynciterable"],
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"declaration": true,
"removeComments": true,
"allowSyntheticDefaultImports": true,
"esModuleInterop": true,
"sourceMap": false,
"outDir": "./dist",
"baseUrl": "./",
"incremental": true,
"skipLibCheck": true,
"strictNullChecks": false,
"noImplicitAny": false,
"strictBindCallApply": false,
"forceConsistentCasingInFileNames": false,
"noFallthroughCasesInSwitch": false,
"strict": true
}
}
I also cloned the example in the repo, but it had no zod-prisma configured at all. So, I added this from README:
generator zod {
provider = "zod-prisma"
output = "./zod"
relationModel = true
// relationModel = "default" // Do not export model without relations.
// relationModel = false // Do not generate related model
modelCase = "PascalCase"
// modelCase = "camelCase" // Output models using camel case (ex. userModel, postModel)
modelSuffix = "Model"
// useDecimalJs = false // (default) represent the prisma Decimal type using as a JS number
useDecimalJs = true
imports = null
// https://www.prisma.io/docs/concepts/components/prisma-client/working-with-fields/working-with-json-fields#filtering-by-null-values
prismaJsonNullability = true
// prismaJsonNullability = false // allows null assignment to optional JSON fields
}
but it also got stuck when I ran npx prisma generate
I use node v14.19.1
I upgraded to latest prisma version:
prisma : 3.13.0
#prisma/client : 3.13.0
Current platform : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/#prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine : migration-engine-cli efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/#prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/#prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary : prisma-fmt efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/#prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash : efdf9b1183dddfd4258cd181a72125755215ab7b
Studio : 0.459.0
Still same issue!
On a side note, I would appreciate it if someone with a rep of 1500 or higher could add the zod-prisma tag.

There was a missing dependency, simply install zod.
Though, the generator should have displayed a warning.
I also submitted a PR to fix this issue for good!

Related

While deploying in serverless Framework im geeting this issue? Deprecation Warning?

Deprecation warning: CLI options definitions were upgraded with "type" property (which could be one of "string", "boolean", "multiple"). Below listed plugins do not predefine type for introduced options: - ServerlessPlugin for "out" - ServerlessOffline for "apiKey", "corsAllowHeaders", "corsAllowOrigin", "corsDisallowCredentials", "corsExposedHeaders", "disableCookieValidation", "enforceSecureCookies", "hideStackTraces", "host", "httpPort", "httpsProtocol", "lambdaPort", "noPrependStageInUrl", "noAuth", "ignoreJWTSignature", "noTimeout", "prefix", "printOutput", "resourceRoutes", "useChildProcesses", "useWorkerThreads", "websocketPort", "webSocketHardTimeout", "webSocketIdleTimeout", "useDocker", "layersDir", "dockerReadOnly", "functionCleanupIdleTimeSeconds", "allowCache", "dockerHost", "dockerHostServicePath", "dockerNetwork" - WarmUp for "warmers" Please report this issue in plugin issue tracker.
Upgrading the "serverless-offline" module to "^8.5.0" fixed my problem
// package.json
"devDependencies": {
"serverless-offline": "^8.5.0"
},
Let me know if this solves your problem.

typeorm:migration create on New Project Does Not Recognize Entities - "No changes in database schema were found - cannot generate a migration."

I'm having trouble creating the initial migration for a nestjs-typeorm-mongo project.
I have cloned this sample project from nestjs that uses typeorm with mongodb. The project does work in that when I run it locally after putting a "Photo" document into my local mongo with db named "test" and collection "photos" then I can call to localhost:3000/photo and receive the photo documents.
Now I'm trying to create migrations with the typeorm cli using this command:
./node_modules/.bin/ts-node ./node_modules/typeorm/cli.js migration:generate -n initial
...but it's not working. I am not able to create an initial commit- even after setting "synchronize: false" in my app.module.ts file I always get the error:
No changes in database schema were found - cannot generate a migration. To create a new empty migration use "typeorm migration:create" command
when trying to generate a migration... đŸ¤”
Other than changing synchronize to false, the only other change I made was adding an ormconfig.json file in the project root by running typeorm init --database mongodb:
{
"type": "mongodb",
"database": "test",
"synchronize": true,
"logging": false,
"entities": [
"src/**/*.entity.ts"
],
"migrations": [
"src/migration/**/*.ts"
],
"subscribers": [
"src/subscriber/**/*.ts"
],
"cli": {
"entitiesDir": "src",
"migrationsDir": "src/migration",
"subscribersDir": "src/subscriber"
}
}
Once you are using MongoDB, you don't have tables and have no need to create your collections ahead of time. Essentially, MongoDB schemas are created on the fly!
Under the hood, if the driver is MongoDB, the command typeorm migration:create is bypassed so it is useless in this case. You can check yourself the PR #3304 and Issue #2867.
However, there is an alternative called migrate-mongo which provides a way to archive incremental, reversible, and version-controlled way to apply schema and data changes. It’s well documented and actively developed.
migrate-mongo example
Run npm install -g migrate-mongo to install it.
Run migrate-mongo init to init the migrations tool. This will create a migrate-mongo-config.js configuration file and a migrations folder at the root of our project:
|_ src/
|_ migrations/
|- 20200606204524-migration-1.js
|- 20200608124524-migration-2.js
|- 20200808114324-migration-3.js
|- migrate-mongo.js
|- package.json
|- package-lock.json
Your migrate-mongo-config.js configuration file may look like:
// In this file you can configure migrate-mongo
const env = require('./server/config')
const config = {
mongodb: {
// TODO Change (or review) the url to your MongoDB:
url: env.mongo.url || "mongodb://localhost:27017",
// TODO Change this to your database name:
databaseName: env.mongo.dbname || "YOURDATABASENAME",
options: {
useNewUrlParser: true, // removes a deprecation warning when connecting
useUnifiedTopology: true, // removes a deprecating warning when connecting
// connectTimeoutMS: 3600000, // increase connection timeout up to 1 hour
// socketTimeoutMS: 3600000, // increase socket timeout up to 1 hour
}
},
// The migrations dir can be a relative or absolute path. Only edit this when really necessary.
migrationsDir: "migrations",
// The MongoDB collection where the applied changes are stored. Only edit this when really necessary.
changelogCollectionName: "changelog"
};
module.exports = config;
Run migrate-mongo create name-of-my-script to add a new migration script. A new file will be created with a corresponding timestamp.
/*
|_ migrations/
|- 20210108114324-name-of-my-script.js
*/
module.exports = {
function up(db) {
return db.collection('products').updateMany({}, { $set: { quantity: 10 } })
}
function down(db) {
return db.collection('products').updateMany({}, { $unset: { quantity: null } })
}
}
The database changelog: In order to know the current database version and which migration should apply next, there is a special collection that stores the database changelog with information such as migrations applied, and when where they applied.
To run your migrations, simply run the command: migrate-mongo up
You can find a full example in this article MongoDB Schema Migrations in Node.js

Build micronaut native image with hikari datasource

Faced with a problem running micronaut application that was packed in native-image.
I created simple demo application with micronaut-data-hibernate-jpa and based on documentation I need to add some db connection pool. I chose hikari and added such dependency micronaut-jdbc-hikari.
I use maven as build tool and add plugin to build native-image native-image-maven-plugin
native-image.properties
Args = -H:IncludeResources=logback.xml|application.yml|bootstrap.yml \
-H:Name=demo \
-H:Class=com.example.Application \
-H:+TraceClassInitialization \
--initialize-at-run-time=org.apache.commons.logging.LogAdapter$Log4jLog,org.hibernate.secure.internal.StandardJaccServiceImpl,org.postgresql.sspi.SSPIClient,org.hibernate.dialect.OracleTypesHelper \
--initialize-at-build-time=org.postgresql.Driver,org.postgresql.util.SharedTimer,org.hibernate.engine.spi.EffectiveEntityGraph,org.hibernate.engine.spi.LoadQueryInfluencers
When I run application with the jvm then everything works. But when I try to run same application that was packed as native-image then I get such error
Caused by: java.lang.IllegalArgumentException: Class com.zaxxer.hikari.util.ConcurrentBag$IConcurrentBagEntry[] is instantiated reflectively but was never registered. Register the class by using org.graalvm.nativeimage.hosted.RuntimeReflection
at com.oracle.svm.core.graal.snippets.SubstrateAllocationSnippets.arrayHubErrorStub(SubstrateAllocationSnippets.java:280)
at java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:305)
at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
at java.lang.ThreadLocal.get(ThreadLocal.java:172)
at com.zaxxer.hikari.util.ConcurrentBag.borrow(ConcurrentBag.java:129)
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:179)
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:161)
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)
at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:122)
at org.hibernate.internal.NonContextualJdbcConnectionAccess.obtainConnection(NonContextualJdbcConnectionAccess.java:38)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.acquireConnectionIfNeeded(LogicalConnectionManagedImpl.java:104)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getPhysicalConnection(LogicalConnectionManagedImpl.java:134)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.getConnectionForTransactionManagement(LogicalConnectionManagedImpl.java:250)
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.begin(LogicalConnectionManagedImpl.java:258)
at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.begin(JdbcResourceLocalTransactionCoordinatorImpl.java:246)
at org.hibernate.engine.transaction.internal.TransactionImpl.begin(TransactionImpl.java:83)
at org.hibernate.internal.AbstractSharedSessionContract.beginTransaction(AbstractSharedSessionContract.java:471)
at io.micronaut.transaction.hibernate5.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:352)
... 99 common frames omitted
UPDATE/SOLUTION
Based on #Airy answer I have added reflection config in native-image.properties. In my case it is looks like so
[
{
"name" : "com.zaxxer.hikari.util.ConcurrentBag",
"allDeclaredConstructors" : true,
"allPublicConstructors" : true,
"allDeclaredMethods" : true,
"allPublicMethods" : true,
"allDeclaredClasses" : true,
"allPublicClasses" : true
},
{
"name" : "com.zaxxer.hikari.pool.PoolEntry",
"allDeclaredConstructors" : true,
"allPublicConstructors" : true,
"allDeclaredMethods" : true,
"allPublicMethods" : true,
"allDeclaredClasses" : true,
"allPublicClasses" : true
}
]
And another solution is to change scope of hikari dependency to compile and add missed fields/classes into hints annotation like so
#TypeHint(value = {
PostgreSQL95Dialect.class,
SessionFactoryImpl.class,
org.postgresql.PGProperty.class,
UUIDGenerator.class,
com.zaxxer.hikari.util.ConcurrentBag.class, // In my case I have just added this line
}, accessType = {TypeHint.AccessType.ALL_PUBLIC})
whole example you can find here
You should declare reflection configuration in your native-image.properties with -H:ReflectionConfigurationFiles=/path/to/reflectconfig
Here is the documentation for doing so

Problem with cloudformation stack update and launch template version / autoscaling group

I have a stack in cloudformation (ECS cluster, App LB, Autoscaling Group, launch templates, etc etc.) It all works fine and we have been using this in production and pre production environments for a while.
A problem recently arose while trying to push a stack update. I made some changes to UserData in the AWS::EC2::LaunchTemplate. If i launch a new stack from this template it works great.
BUT:
If i make a change set and apply a stack update cloudformation creates a NEW launch template version -however- the autoscaling group still references the OLD version.
Looking at the AWS docs for AWS::AutoScaling::AutoScalingGroup LaunchTemplateSpecification
I see:
"AWS CloudFormation does not support specifying $Latest, or $Default for the template version number."
Anyone wrangled w/ stack updates creating new versions of resources that need to be referenced elsewhere? I feel like i am missing something obvious.
yay, i'm dumb:
use Fn::GetAtt
ok, make fun of me for using json not yaml
...
"ECSAutoScalingGroup": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"VPCZoneIdentifier": {"Ref" : "Subnets"},
"MinSize": "1",
"MaxSize": "10",
"DesiredCapacity": { "Ref": "DesiredInstanceCount" },
"MixedInstancesPolicy": {
"InstancesDistribution" :
{
"OnDemandBaseCapacity" : "0",
"OnDemandPercentageAboveBaseCapacity" : { "Ref" : "PercentOnDemand"}
},
"LaunchTemplate" : {
"LaunchTemplateSpecification" : {
"LaunchTemplateId" : {"Ref" : "ECSLaunchTemplate"},
"Version" : { "Fn::GetAtt" : [ "ECSLaunchTemplate", "LatestVersionNumber" ] }
},
"Overrides" : [ {"InstanceType": "m5.xlarge"},{"InstanceType": "t3.xlarge"},{"InstanceType": "m4.xlarge" },{"InstanceType": "r4.xlarge"},{"InstanceType": "c4.xlarge"}]
}
}
},
...

Migrating to Meteor 1.7.0.4 : MongoDB : "updating the path ... would create a conflict at ..."

Im using meteor, and im trying to go from meteor 1.6 to 1.7
But im encountering errors im unable to get informations about in my tests :
tests.jpg
I get multiple things like this (some are maybe redondant, unused or obsolete) :
Error: Updating the path 'relationChangeRate' would create a conflict at 'relationChangeRate'
at Function.MongoError.create (C:\Users\fquesselaire\AppData\Local\.meteor\packages\npm-mongo\3.0.11\npm\node_modules\mongodb-core\lib\error.js:45:10)
at toError (C:\Users\fquesselaire\AppData\Local\.meteor\packages\npm-mongo\3.0.11\npm\node_modules\mongodb\lib\utils.js:149:22)
at C:\Users\fquesselaire\AppData\Local\.meteor\packages\npm-mongo\3.0.11\npm\node_modules\mongodb\lib\collection.js:1029:39
at C:\Users\fquesselaire\AppData\Local\.meteor\packages\npm-mongo\3.0.11\npm\node_modules\mongodb-core\lib\connection\pool.js:544:18
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickDomainCallback (internal/process/next_tick.js:218:9)
not occurring in 1.6.*
I tried upgrade my mongodb to 3.6.6, no effect.
Im also unable to get the entire stack in tests to see what is exactly enforcing.
my .meteor/versions :
255kb:meteor-status#1.5.0
accounts-base#1.4.2
accounts-password#1.5.1
akasha:fs-extra#0.26.3
alanning:roles#1.2.16
aldeed:autoform#6.3.0
aldeed:autoform-bs-button-group-input#2.0.0
aldeed:autoform-select2#3.0.1
aldeed:collection2-core#2.1.2
aldeed:template-extension#4.1.0
allow-deny#1.1.0
arillo:flow-router-helpers#0.5.2
autoupdate#1.4.1
babel-compiler#7.1.1
babel-runtime#1.2.4
base64#1.0.11
binary-heap#1.0.10
blaze#2.3.2
blaze-html-templates#1.1.2
blaze-tools#1.0.10
boilerplate-generator#1.5.0
caching-compiler#1.1.12
caching-html-compiler#1.1.3
callback-hook#1.1.0
check#1.3.1
coffeescript#1.0.17
cultofcoders:mocha#2.4.6
dburles:collection-helpers#1.1.0
dburles:factory#1.1.0
ddp#1.4.0
ddp-client#2.3.3
ddp-common#1.4.0
ddp-rate-limiter#1.0.7
ddp-server#2.2.0
deps#1.0.12
diff-sequence#1.1.0
dynamic-import#0.4.1
ecmascript#0.11.1
ecmascript-runtime#0.7.0
ecmascript-runtime-client#0.7.2
ecmascript-runtime-server#0.7.1
ejson#1.1.0
email#1.2.3
es5-shim#4.8.0
fourseven:scss#4.9.0
geojson-utils#1.0.10
hot-code-push#1.0.4
html-tools#1.0.11
htmljs#1.0.11
http#1.4.1
id-map#1.1.0
idmontie:migrations#1.0.3
jquery#1.11.11
kadira:blaze-layout#2.3.0
kadira:flow-router#2.12.1
lai:collection-extensions#0.2.1_1
launch-screen#1.1.1
livedata#1.0.18
lmieulet:meteor-coverage#1.1.4
localstorage#1.2.0
logging#1.1.20
matb33:collection-hooks#0.8.4
meteor#1.9.2
meteor-base#1.4.0
meteorhacks:picker#1.0.3
meteortesting:browser-tests#1.0.0
meteortesting:mocha#1.0.0
minifier-css#1.3.1
minifier-js#2.3.5
minimongo#1.4.4
mobile-experience#1.0.5
mobile-status-bar#1.0.14
modern-browsers#0.1.2
modules#0.12.2
modules-runtime#0.10.2
momentjs:moment#2.22.2
mongo#1.5.1
mongo-dev-server#1.1.0
mongo-id#1.0.7
mouse0270:bootstrap-notify#3.1.3
natestrauser:select2#4.0.3
npm-bcrypt#0.9.3
npm-mongo#3.0.11
observe-sequence#1.0.16
ordered-dict#1.1.0
ostrio:cookies#2.3.0
ostrio:files#1.10.1
practicalmeteor:chai#2.1.0_1
practicalmeteor:loglevel#1.2.0_2
practicalmeteor:mocha-core#1.0.1
practicalmeteor:sinon#1.14.1_2
promise#0.11.1
raix:eventemitter#0.1.3
random#1.1.0
rate-limit#1.0.9
reactive-dict#1.2.1
reactive-var#1.0.11
reload#1.2.0
retry#1.1.0
rocketchat:streamer#0.5.0
routepolicy#1.0.13
service-configuration#1.0.11
session#1.1.8
sewdn:collection-behaviours#0.3.0
sha#1.0.9
shell-server#0.3.1
socket-stream-client#0.2.2
softwarerero:accounts-t9n#1.3.11
spacebars#1.0.15
spacebars-compiler#1.1.3
srp#1.0.12
standard-minifier-css#1.4.1
standard-minifier-js#2.3.4
templating#1.3.2
templating-compiler#1.3.3
templating-runtime#1.3.2
templating-tools#1.1.2
tmeasday:check-npm-versions#0.3.2
tmeasday:test-reporter-helpers#0.2.1
tracker#1.2.0
ui#1.0.13
underscore#1.0.10
url#1.2.0
useraccounts:bootstrap#1.14.2
useraccounts:core#1.14.2
useraccounts:flow-routing#1.14.2
webapp#1.6.2
webapp-hashing#1.0.9
zimme:active-route#2.3.2
my node packages :
"dependencies": {
"#babel/runtime": "^7.0.0-beta.54",
"#mdi/font": "^2.5.94",
"babel-runtime": "^6.26.0",
"bcrypt": "^3.0.0",
"bootstrap": "^3.3.7",
"bootstrap-material-design": "^0.5.10",
"bootstrap-slider": "^10.0.2",
"bootstrap-toggle": "^2.2.2",
"clone": "^2.1.1",
"csv-parse": "^2.5.0",
"d3": "^5.5.0",
"file-saver": "^1.3.8",
"fs-extra": "^3.0.1",
"gm": "^1.23.0",
"jquery": "^2.2.4",
"jsondiffpatch": "^0.3.11",
"lodash": "^4.17.10",
"meteor-node-stubs": "^0.4.1",
"mkdirp": "^0.5.1",
"object-path": "^0.11.4",
"popper.js": "^1.14.3",
"select2": "^4.0.4",
"select2-bootstrap-theme": "^0.1.0-beta.10",
"simpl-schema": "^1.5.3",
"uuid": "^3.3.2",
"xmldoc": "^1.1.0",
"zip-local": "^0.3.4"
},
"devDependencies": {
"chromedriver": "^2.40.0",
"gulp": "^3.9.1",
"selenium-webdriver": "^3.6.0"
}
if you have any clue about what is going on ?
i can give more informations about what's happening in the app, but right now a simple explain about what this error mean would be awesome already. as i said, this error only append in 1.7.
EDIT: forget to say that my test throw this on WORKING code.
Features are working well, but not the tests.
EDIT²:
This method is the one that update the collection projectSettings.
_duplicateProjectSettings(newSession) {
const settings = this.session.projectSettings();
delete settings._id;
settings.sessionId = newSession._id;
const newSettings = newSession.projectSettings();
ProjectSettings.update(newSettings._id, { $set: settings });
}
relationChangeRate is a simpl-schema field of projectSettings collection as it (i use collection2-core) :
relationChangeRate: {
type: Number,
allowedValues: _.values(RelationRates),
defaultValue: 0.0
}
projectSettings extends mongo.collection, but in this case, update method is not override.
The code seams correct to me, as the _id is well removed and set to the new object before update request. but maybe im wrong ?
EDIT³:
ProjectSettings is a collection-helper:
Here is the code :
Sessions.helpers({
[...]
projectSettings() {
const conds = { sessionId: this._id };
return ProjectSettings.findOne(conds);
},
[...]
A collection helper basically add a method on each document from this collection. It means that any session object will have this method. In a collection helper, "this" refer to the current collection object.
so should be good ?
_duplicateProjectSettings could be write like this:
_duplicateProjectSettings(newSession) {
// const settings = this.session.projectSettings();
const settings = ProjectSettings.findOne({ sessionId: this.session._id });
delete settings._id;
settings.sessionId = newSession._id;
// const newSettings = newSession.projectSettings();
const newSettings = ProjectSettings.findOne({ sessionId: newSession._id });
ProjectSettings.update(newSettings._id, { $set: settings });
}
(I tried it too, same result)
Running this from shell worked for me... not the best solution. I had the problem when I tried to login with accounts-password package.
$ meteor mongo
meteor:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
Ok,
This is an half-answer but
After some extended search i figured that i had a test script that reset MONGO_URL as follow :
set MONGO_URL=
set TEST_BROWSER_DRIVER=chrome
set TEST_WATCH=1
set TEST_CLIENT=0
set TEST_SERVER=1
meteor test -p 3100 --driver-package=cultofcoders:mocha %*
after figuring that i launched the tests on my local dev db, and tests passed (smashing my db by the way lol). So, it means it could be version related, or test-conditions related.
I am not able to print the version of mongodb used for tests, so i don't know the tests conditions exactly.
All i know is so :
Meteor "normal run" Mongo version : 3.6.4
My local Mongo version : 3.6.6