Occasional WriteConcernException with unexpected error message "trying to match on unknown field: personId", "code" : 16920
Kevin Dosey
I'm looking for a little help in understanding what is going on when we occasionally get this exception on our system:
com.mongodb.WriteConcernException: { "serverUsed" : "server2:27017", "ok": 1, "n": 0, "updatedExisting": false, "err": "trying to match on unknown field: personId", "code" : 16920}
I think it relates to this line, https://github.com/mongodb/mongo/blob/master/src/mongo/db/exec/filter.h#L84 which has a comment right above says that it should not happen.
I am unable to reproduce this on my local system. We're using mongo java driver 2.13, connecting to a mongo cluster of 3 nodes running mongo 3.0.6. We've noticed that there is a typo in our compound index, that it's referencing person.id, rather than personId. However, we don't think that should matter to mongo, other than not being able to use the index we intended. We would expect that if this error were truly about the index, we would get this error on every write, but we don't. For example, we write to this collection via the same code multiple times a day, and the last time we saw this exception was early last week.
We can fix the index of course, but we'd like to understand why we only see this error occasionally. Specifically, I'm hoping someone may have some insight into why it's happening or possible steps to at least help reproduce the issue so we can move forward with debugging.
Thank you for your time,
Kevin D.
Wan Bachtiar
We’ve noticed that there is a typo in our compound index, that it’s referencing person.id, rather than personId. However, we don’t think that should matter to mongo, other than not being able to use the index we intended. We would expect that if this error were truly about the index, we would get this error on every write, but we don’t
Hi Kevin,
Based on the code that you are referring to, it’s a part of code for sharding filter.
If you are inserting to a sharded cluster, make sure all of connections in your application code are connecting via mongos instead of mongod instance. Unlike mongod, a mongos will prevent inserts of documents without the shard key pattern for the collection. This would have caught the typo of the compound index earlier.
We can fix the index of course, but we’d like to understand why we only see this error occasionally.
You should also correct any documents in specific shards that don’t contain the shard key pattern.
If you still have further questions, could you post the relevant details of:
- Example document structures
- The compound index structures
- If known, the specific Java code that generates the
WriteConcernException.
Kind regards,
Wan.
Kevin Dosey
Thank you for responding. Our cluster is setup for replication, we're currently not using sharding. Given that we're not using sharding, do you think just fixing the index would be enough to fix the problem?
Unfortunately I'm unable to provide exact examples, but I can try to give you more information:
- Our document in question has at least the following fields: begin, end, personId, and count.
- The compound index is on begin, and, and person.id (should be personId)
- We're using spring-data-mongodb so, basically an update call to the collection in our code causes the exception to occur occasionally.
Wan Bachtiar
Given that we’re not using sharding, do you think just fixing the index would be enough to fix the problem?
Hi Kevin,
I would recommend to correct the index key regardless, otherwise the index key will not be able to be utilised effectively if it’s pointing to an undefined field. See Compound Index to see more information.
We’re using spring-data-mongodb so, basically an update call to the collection in our code causes the exception to occur occasionally.
I’ve tried to replicate the issue by using MongoDB v3.0.6 replica set with a compound index of two fields - begin and person.id where the documents don't have person.id field. Using update() with writeConcern I could not reproduce the error that you are seeing.
It would be great, if you could provide a simpler example to reproduce the problem. Also note that spring-data-mongodb is a community supported project.
Kind Regards,
Wan.
Kevin Dosey
Providing the example is the difficult part, I've not been able to narrow down what is causing the problem, to be able to reproduce it myself. In any of my tests, I've not been able to generate the exception. We only see it rarely in production with no discernible pattern so far.
I guess at this point, we can fix the index and wait to see if we see the same or a different error, or any at all. We just wanted to see if we could find out the real issue before blindly fixing the index.