[SERVER-12349] Insert from update replaces {_id:Timestamp()} with current date+inc Created: 13/Jan/14  Updated: 09/Oct/19  Resolved: 27/Jan/14

Status: Closed
Project: Core Server
Component/s: Replication, Write Ops
Affects Version/s: None
Fix Version/s: 2.5.5

Type: Bug Priority: Major - P3
Reporter: Craig Wilson Assignee: Scott Hernandez (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
causes SERVER-43014 Timestamp(0,0) not filled in for _id ... Closed
Related
related to SERVER-12302 Breaking Change: Timestamp(0,0) now r... Closed
Backwards Compatibility: Major Change
Operating System: ALL
Steps To Reproduce:
  1. Startup a replica set.
  2. launch shell to primary
  3. Executed db.foo.insert({_id:Timestamp()})
  4. Secondary dies.
Participants:

 Description   

When inserting a document into a collection using a Timestamp as the identifier, if the time and ordinal are both 0, the secondary fails on replication and throws an fassert failure causing mongod to die. In addition, any attempt to restart the secondary will fail as that same op will attempt to replicate and cause the same exception again. This is a change in behavior from the previous 2.4 release line.

I tried this with other combinations of timestamps, both in value and in location in the document and it's always when the timestamp is _id with 0's for both of its components.

2014-01-13T14:03:24.987-0600 [repl writer worker 1] ERROR: writer worker caught
exception:  :: caused by :: 16836 The _id field cannot be changed from {_id: Timestamp 0|0} to {_id: Timestamp 1389643404000|1}. on: { ts: Timestamp 1389643404000|1, h: -2969864546816060428, v: 2, op: "i", ns: "test.foo", o: { _id: Timestamp 0|0 } }
2014-01-13T14:03:24.987-0600 [repl writer worker 1] Fatal Assertion 16360
2014-01-13T14:03:24.987-0600 [repl writer worker 1]
 
***aborting after fassert() failure



 Comments   
Comment by Githook User [ 27/Jan/14 ]

Author:

{u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}

Message: SERVER-12349: don't replace _id Timestamp, but replace all toplevel Timestamp(0,0) - like insert
Branch: master
https://github.com/mongodb/mongo/commit/e7160fcd26cc0508f9fe2a47bb0a78561250565d

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

Craig, the _id being replaced before was the bug, which is now fixed in insert, but was still broken in update (w/upsert:true -> insert). We have also expanded timestamp replacement to support all top-level fields (except _id).

Now the _id field will be immutable and will not do the replacement, and I hope most people would expect.

eliot, let me know if this was not the way we wanted to go. Also, I will file another improvement for this state ({_id:Timestamp()}) to be an error since that would catch anyone doing this rather then just silently failing on the first one (since the second one will result in a conflict of Timestamp(0,0) on the unique _id index).

Craig, if you have use-cases for using the _id as an expanding unique Timestamp, please file a new issue and we can discuss there and about the use-case(s).

Comment by Craig Wilson [ 13/Jan/14 ]

I see the change in the title of the ticket. It's much more explanatory, but it seems backwards. I think the correct statement is that

{ _id: Timestamp() }

is NOT expanded on insert on the primary. This is different behavior than in 2.4.

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