mongoose-patch-history
mongoose-patch-history copied to clipboard
Timeout upon saving a new document
I'm new to document versioning and have been trialing on a few similar plugins. It may be my mis-configuration, but I have really no idea what's going wrong after attempting for a whole day...
When I comment out the plugin-related script, Mongoose works as expected. But if the plugin is applied, new document cannot be saved and results in timeout...
Debug: handler, error
Error: Operation `issue_patches.insertOne()` buffering timed out after 10000ms
at Toolkit.badRequest (...\microservice-issue\lib\boom.js:43:34)
at handler (...\microservice-issue\lib\controllers\issue.js:95:16)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Below is my models/issue.js
.
'use strict'
const Mongoose = require('mongoose')
// const History = require('mongoose-patch-history').default
const issueSchema = new Mongoose.Schema({
trelloId: String,
trelloUrl: String,
parcelNo: String,
warehouse: String,
courier: String,
issueReason: Number,
photo: [{
url: String,
remark: String
}],
status: {
type: String,
default: 'To Do'
},
updatedBy: String
})
// issueSchema.plugin(History, {
// mongoose: Mongoose,
// name: 'issuePatches'
// })
module.exports = {
name: 'Issue',
schema: issueSchema
}
Versions: node: 12.18.4 mongodb: 4.2.11 mongoose: 5.11.4 mongoose-patch-history: 2.0.0
Appreciate any help. Thank you!
Sounds strange. Can you provide a simplified example repository that allows to reproduce this and versioning information for everything that's not versioned through your repo like mongodb itself?
Hey @hk7math,
this could possibly be related to #73. Could you try out the code from this branch or else downgrade your mongoose version to <= 5.9.6
as stated here https://github.com/codepunkt/mongoose-patch-history/issues/71#issuecomment-699845276.
Sounds strange. Can you provide a simplified example repository that allows to reproduce this and versioning information for everything that's not versioned through your repo like mongodb itself?
I remake an example repo for my case.
It used hpal
to boilerplate a hapi
server, and I added some routes with mongodb
connection (4.2.11)
Mongo related scripts are here:
-
lib/index.js
does the mongodb connection -
lib/.hc.js
bundles the model to hapi specific handler -
lib/models/Riddle.js
should be the main focus.mongoose-patch-history
related scripts are commented now. When uncommented, any POST will go timeout =(
this could possibly be related to #73. Could you try out the code from this branch or else downgrade your mongoose version to <=
5.9.6
as stated here #71 (comment).
I tried downgrading mongoose version with the following npm list mongoose
result.
The timeout still happens with the plugin but POST goes properly without it.
npm list mongoose
[email protected] [masked project path]
+-- [email protected]
`-- [email protected]
`-- [email protected] deduped
Thank you very much!
For reference, it seems other people encounter similar error on Mongoose Repo However, my example runs fine when the patch plugin is not used.. ><
I can say that the issue discussed here is somehow related to the saving of the patch.
In mongoose
there are 2 options (probably) to save a new document. Either with schema.create()
or with new model(doc).save()
. Both calls result in timeouts, if called on our Patches Schema
, but work fine if called on your Riddle Schema
.
I may have time this evening to do some further debugging. However I don't know if this is related to the mongoose issue you pointed at, since this is relatively new and our issue arises even with older versions of mongoose.
This may be related to how the mongoose connection is defined or how hapi
manages these connections. I will probably know more in the evening.
Thanks for adding additional info @hk7math!
Summary
The timeout error origins in an undefined mongoose connection for our mongoose-patch-history
plugin.
Quick workaround: Change Mongoose.createConnection()
to Mongoose.connect()
in lib/index.js
. This uses the default mongoose connection instead of creating a new one.
Details
Background Knowledge
The mongoose-patch-history
plugin retrieves the used mongoose connection (instance) from the options as stated in the documentation (first parameter).
Usually one just imports/requires the mongoose
module and give that as a parameter. Happening under the hood is the following:
- Mongoose maintains an internal connections array which is pre-initialized with a default connection (state = disconnected)
- Plugin uses options.mongoose.model(PatchSchema) to create the model used for saving patches to the db
-
mongoose.model
uses the connection assigned to the mongoose-instance which, in this case is the default mongoose connection which is defined asmongoose.connections[0]
, the pre-initialized connection mentioned in 1.
Specific error
In your sample repo you pass the default imported mongoose instance as done in our usage example.
This default mongoose instance however has no connection assigned to it, since the connection is created with Mongoose.createConnection. createConnection()
adds a new connection to the connections array maintained by the mongoose instance.
Since a new connection is added, the default connection (connections[0]) is still uninitialized. Hence our plugin has no connection to work with.
Solutions
- Exchange
createConnection()
withconnect()
(example-repo-ref) to use the default mongoose connection instead of creating a new one. - Predefine the (uninitialized) connection with
const db = mongoose.createConnection();
and pass that to the mongoose-patch-history-plugin options. After open the connection withdb.openUri(...)
. (mongoose-doc-ref)
@codepunkt I think a PR is needed where the connection state is examined before each patch operation. If the connection is not in state connected
we can either throw an error or wait for a timeout (maybe add an option for this) and then throw an error.
I'd see this error as a user error but nevertheless we can improve on user experience with a good error msg.
I'd of course volunteer to tackle this but only if you have the time to review and merge the PR, or else we are talking about the maintainer role again.