[SERVER-14933] Failed to insert into capped collection when collection contains invalid 2d data Created: 18/Aug/14 Updated: 11/Jul/16 Resolved: 04/Nov/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo, Index Maintenance |
| Affects Version/s: | 2.6.3 |
| Fix Version/s: | 2.7.8 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jianfa Tang (Inactive) | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: |
Expected: document #3 to be inserted, #1 to be removed Assertion: 12583:unexpected index insertion failure on capped collection However the document is inserted nevertheless. By the time when Mongo tries to remove the index for document #1, we get the "unindex failed" error. The desired behavior is Mongo should fail the document insertion if there is an error creating the 2d index. This would be consistent with the new behavior in 2.6 with regard to the long index key handling |
||||||||||||
| Participants: | |||||||||||||
| Description |
|
With a capped collection that stores taxi driver's location data. They have a 2d index in addition to the _id index on that collection. What they noticed is that once the collection is full, they are not able to inserting new document because of following error: unindex failed (key too big?) order.order_endloc.$id key: { : ObjectId('53e3a3cb0cf25dc1e46cc2a2') } _id: ObjectId('53e3a3cb0cf25dc1e46cc2a2') They were not able to reproduce this in test environment so had to use the workaround of dropping the collection when it's full and start over. I spent some time with them today and was able to figure out the root cause to be some invalid location data. See repro steps for details. |
| Comments |
| Comment by Mathias Stearn [ 04/Nov/14 ] |
|
I think this was automatically fixed by automatic rollback introduced by |
| Comment by Greg Studer [ 26/Sep/14 ] |
|
Issue is not really geo-specific, but occurs because rollback on capped collections works differently than in ordinary collections. |