[SERVER-19091] Validate that BSON returned to clients doesn't contain duplicate field names Created: 23/Jun/15 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Max Hirschhorn | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
Some drivers will error if the BSON returned by the server contains duplicate field names. The handling of WriteConflictExceptions in commands while mutating the BSONObjBuilder& result has led to a few bugs in 3.0: We should add some code for debug-enabled builds that validates BSON returned to the client. |
| Comments |
| Comment by Ian Whalen (Inactive) [ 30/Jun/17 ] |
|
acm got it. david.storch will talk with you to help clarify what falls to which team. |
| Comment by Scott Hernandez (Inactive) [ 23/Jun/15 ] |
|
I have cleaned up the other server issue so it is less of a dup, but I believe that we should only check non-user data if we do this and it make it clean that the scope of this issue is not to eliminate duplicated fields until we decide that restriction applies to user data, and we have a plan for replication and sharding as well. |
| Comment by Scott Hernandez (Inactive) [ 23/Jun/15 ] |
|
A dup of SERVER-6439 (which needs a bit of cleanup). |