Ticket: Timeouts - Return from api incorrect

Hi all,

The test npm test -t timeouts is passing but the status page tells me that Timeouts: The return from the api was incorrect. What should i recheck ? Thanks.

Make sure you actually changed the appropriate setting in both places. This is actually stated on the question page.

For the “unit tests” you edit the setting in : test/config/mongoEnvironment.js

But for the “mflix” application you actually need to change the index.js


Testing and Running the Application

Note:

The unit test only has access to DAO methods, but the write timeout for the MFlix application is set in the index.js file.

However, the write timeout for the testing environment is set intest/config/mongoEnvironment.js, so you can test your changes there and the unit test will tell you if something is wrong.

When the unit test passes, make sure to update the code in src/index.js so you can retrieve the validation code from the integration test.

Yes i did change the settings in both mongoEnvironment.js & index.js

Your result says you likely did not. Check it again.

Please note this is not a chat room. If you get a response you probably should walk away and look at it thoroughly instead of responding right away.

Could you share what your connection information looks like now after setting the appropriate values in the options argument?

Make sure you’re on the src/index.js file and not on the index.js file which is in the root folder of the mflix app.

2 Likes

Hi Nathan, Wouldn’t that be sharing the answer ? I assume you are referring to the connection information in src/index and test/mongoEnvironment.js. In test/mongoEnvironment.js i have

async setup() {
    if (!this.global.mflixClient) {
          this.global.mflixClient = await MongoClient.connect(
            process.env.MFLIX_DB_URI,
                    //  the poolsize and write timeout entry here
            { useNewUrlParser: true }
 )
      await super.setup()
    }
  }

In src/index.js i have ,

MongoClient.connect(
  process.env.MFLIX_DB_URI,
// the pool size and write timeout entry here
  { useNewUrlParser: true },
)

I am on src/index.js. I have put the respective connection parameters to src/index.js and test/mongoEnvironment.js in my answer to @nathan.leniz below. Thank you.

If what you mean you did was basically:

.connect(
   process.env.MFLIX_DB_URI,  
  { notThePoolSizeOption: 999, notTheTimeout: 999 },
  { useNewUrlParser: true }
)

Then that would be incorrect as the “options” part is one section and not two.

You should have something like:

.connect(
   process.env.MFLIX_DB_URI,  
   { 
     notThePoolSizeOption: 999,
     notTheTimeout: 999,
     useNewUrlParser: true
   }
)

And of course the actual named options are all in the MongoClient documentation, not to mention the fact that they are both named in the unit tests of course.

The actual getConfiguration() method is in the moviesDAO and it’s something you don’t need to change. Both the front end /status and the unit tests are reading from this method, so the only difference is the two named files and what options you actually put in them.

I have a similar issue as this original post except I my unit test fails . My poolsize ticket worked fine but the timeout ticket fails.

Expected: 2500
Received: undefined

My options are in order of your example. I am working in the mongoEvironment.js as the ticket indicates first until the test succeeds.

My Error

Try specifying the options in the URI rather than using parameters. See


and look for wtimeout.

I tried setting the wtimeoutMS option in the URI string (.env file ) but the test and Status page still failed.

Have you check the following:

I did indicate I have been working in the mongoEnvironment.js. I run the unit test “npm test -t timeouts” but I have also updated index.js with the same wtimeout: 2500, setting with the same results.

From https://mongodb.github.io/node-mongodb-native/driver-articles/mongoclient.html#mongoclient-connect-options, and if I understand correctly, it looks like the options should be written:

{
  db : { wtimeout : 2500 } ,
  server : {  poolSize : 50 }
}

May be it is a new syntax. May that what’s the error Top level use of w, wtimeout, j … is deprecated.

Give it a try. If it works we will both have learn.

1 Like

the server/replset/mongos/db options are deprecated, all their options are supported at the top level of the options object [poolSize,ssl,sslValidate,sslCA,sslCert,sslKey,sslPass,sslCRL,autoReconnect,noDelay,keepAlive,keepAliveInitialDelay,connectTimeoutMS,family,socketTimeoutMS,reconnectTries,reconnectInterval,ha,haInterval,replicaSet,secondaryAcceptableLatencyMS,acceptableLatencyMS,connectWithNoPrimary,authSource,w,wtimeout,j,writeConcern,forceServerObjectId,serializeFunctions,ignoreUndefined,raw,bufferMaxEntries,readPreference,pkFactory,promiseLibrary,readConcern,maxStalenessSeconds,loggerLevel,logger,promoteValues,promoteBuffers,promoteLongs,domainsEnabled,checkServerIdentity,validateOptions,appname,auth,user,password,authMechanism,compression,fsync,readPreferenceTags,numberOfRetries,auto_reconnect,minSize,monitorCommands,retryWrites,retryReads,useNewUrlParser,useUnifiedTopology,serverSelectionTimeoutMS,useRecoveryToken,autoEncryption,driverInfo,tls,tlsInsecure,tlsinsecure,tlsAllowInvalidCertificates,tlsAllowInvalidHostnames,tlsCAFile,tlsCertificateFile,tlsCertificateKeyFile,tlsCertificateKeyFilePassword,minHeartbeatFrequencyMS,heartbeatFrequencyMS,directConnection,appName,maxPoolSize,minPoolSize,maxIdleTimeMS,waitQueueTimeoutMS]
the server/replset/mongos/db options are deprecated, all their options are supported at the top level of the options object [poolSize,ssl,sslValidate,sslCA,sslCert,sslKey,sslPass,sslCRL,autoReconnect,noDelay,keepAlive,keepAliveInitialDelay,connectTimeoutMS,family,socketTimeoutMS,reconnectTries,reconnectInterval,ha,haInterval,replicaSet,secondaryAcceptableLatencyMS,acceptableLatencyMS,connectWithNoPrimary,authSource,w,wtimeout,j,writeConcern,forceServerObjectId,serializeFunctions,ignoreUndefined,raw,bufferMaxEntries,readPreference,pkFactory,promiseLibrary,readConcern,maxStalenessSeconds,loggerLevel,logger,promoteValues,promoteBuffers,promoteLongs,domainsEnabled,checkServerIdentity,validateOptions,appname,auth,user,password,authMechanism,compression,fsync,readPreferenceTags,numberOfRetries,auto_reconnect,minSize,monitorCommands,retryWrites,retryReads,useNewUrlParser,useUnifiedTopology,serverSelectionTimeoutMS,useRecoveryToken,autoEncryption,driverInfo,tls,tlsInsecure,tlsinsecure,tlsAllowInvalidCertificates,tlsAllowInvalidHostnames,tlsCAFile,tlsCertificateFile,tlsCertificateKeyFile,tlsCertificateKeyFilePassword,minHeartbeatFrequencyMS,heartbeatFrequencyMS,directConnection,appName,maxPoolSize,minPoolSize,maxIdleTimeMS,waitQueueTimeoutMS]
(node:15140) Warning: Accessing non-existent property ‘MongoError’ of module exports inside circular dependency
(Use node --trace-warnings ... to show where the warning was created)
(node:15140) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.
Top-level use of w, wtimeout, j, and fsync is deprecated. Use writeConcern instead.
Top-level use of w, wtimeout, j, and fsync is deprecated. Use writeConcern instead.
Top-level use of w, wtimeout, j, and fsync is deprecated. Use writeConcern instead.
Top-level use of w, wtimeout, j, and fsync is deprecated. Use writeConcern instead.

i have the same problem with Eric Tomenga
but the db: {wtimeout : 2500} option works for me for the test and the api index.js

with the comon wtimeout: 2500 dont works
someone could explain this, to learn more
thanks

Thank you, i really needed this!!!

This documentation is what worked for me.

Note that writeConcern is what should be used as an object to replace the top level wtimeout, etc.

It is still interesting that I got multiple instances of this warning even though I used writeConcern:

Top-level use of w, wtimeout, j, and fsync is deprecated. Use writeConcern instead.

It would be nice to understand why but I’ll assume the warnings are inconsequential at this time.