[SERVER-12523] When creating collection with autoIndexId set to false, upserts create documents with no _id Created: 29/Jan/14  Updated: 07/Mar/14  Resolved: 29/Jan/14

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Alon Horev Assignee: Scott Hernandez (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian running 2.4.3


Issue Links:
Duplicate
duplicates SERVER-12334 Update does not ensure an _id field Closed
Operating System: ALL
Participants:

 Description   

Bar.py

 
import pymongo
conn = pymongo.Connection()
coll = conn.test.create_collection('bar', autoIndexId=False)
coll.update({'a': 1}, {'$set': {'b': 2}}, upsert=True)
list(coll.find())
[{u'a': 1, u'b': 2}] # NO _id!!

Once _id is missing we saw fatal assertions coming from replica set code (we tried creating the index but it complain on dup key error) and failed migration because migrated documents must contain a _id. I assume all documents in mongo must have a _id.



 Comments   
Comment by Scott Hernandez (Inactive) [ 29/Jan/14 ]

Yes, creating a unique index on _id, when not all your docs have unique _id will cause this. This is expected and correct behavior wrt replication – btw, it didn't crash but simply shutdown due to an unrecoverable error during replication.

The underlying issue will be resolved in the next stable release, but for now you can assign an _id to all your docs before creating the unique _id index.

Comment by Alon Horev [ 29/Jan/14 ]

here's the shard crashing (I redacted some sensitive information):

Wed Jan 29 12:06:13.278 [repl writer worker 2] ERROR: writer worker caught exception: E11000 duplicat
e key error index: son_pms_cell.pms_cell_sum_60min.$id dup key: { : null } on: { ts: Timestamp 139
0997145000|34, h: 1846642910431133670, v: 2, op: "i", ns: "son_pms_cell.pms_cell_sum_60min", o:

{ _id : ObjectId('52e8ee99396c67e5edb38c0a'), cell_id: "foo_030a2b4ac56520110552d09a" }

}
Wed Jan 29 12:06:13.278 [repl writer worker 2] Fatal Assertion 16360
0xdcf361 0xd8f0d3 0xc1f33c 0xd9cc01 0xe17cb9 0x7fdd5726cb50 0x7fdd5660fa7d
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xdcf361]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo13fassertFailedEi+0xa3) [0xd8f0d3]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo7replset14multiSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x12c) [0xc1f33c]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo10threadpool6Worker4loopEv+0x281) [0xd9cc01]
/packages/mongodb-2.4.3/bin/mongod() [0xe17cb9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7fdd5726cb50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fdd5660fa7d]
Wed Jan 29 12:06:13.319 [repl writer worker 2]

***aborting after fassert() failure

Wed Jan 29 12:06:13.319 Got signal: 6 (Aborted).

Wed Jan 29 12:06:13.323 Backtrace:
0xdcf361 0x6cf729 0x7fdd565674f0 0x7fdd56567475 0x7fdd5656a6f0 0xd8f10e 0xc1f33c 0xd9cc01 0xe17cb9 0x7fdd5726cb50 0x7fdd5660fa7d
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xdcf361]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo10abruptQuitEi+0x399) [0x6cf729]
/lib/x86_64-linux-gnu/libc.so.6(+0x324f0) [0x7fdd565674f0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7fdd56567475]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x180) [0x7fdd5656a6f0]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo13fassertFailedEi+0xde) [0xd8f10e]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo7replset14multiSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x12c) [0xc1f33c]
/packages/mongodb-2.4.3/bin/mongod(_ZN5mongo10threadpool6Worker4loopEv+0x281) [0xd9cc01]
/packages/mongodb-2.4.3/bin/mongod() [0xe17cb9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7fdd5726cb50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fdd5660fa7d]

Comment by Scott Hernandez (Inactive) [ 29/Jan/14 ]

Can you post the logs from the server with the replication failures please?

I believe this is a duplicate of something we have fixed for newer versions already: SERVER-12334

Generated at Thu Feb 08 03:28:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.