[SERVER-13145] Javascript Bulk API {w:0} return errors in non-commands mode Created: 11/Mar/14 Updated: 10/May/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 2.6.0-rc1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Andreas Nilsson | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | 26qa, bulk_api, move-sa, neweng, polish | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||
| Steps To Reproduce: |
returns the following error in legacy mode.
|
|||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||
| Description |
|
If running the shell in "commands" mode inserting two documents with identical _id fields and w = 0 gives no error in the bulk API. If however running in non-commands mode then a write error is returned. According to the spec behavior the expected behavior is to not return any error data in the response object (generated by the bulk api code in javascript). |
| Comments |
| Comment by Steven Vannelli [ 10/May/22 ] | ||
|
Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions. | ||
| Comment by Scott Hernandez (Inactive) [ 30/Apr/14 ] | ||
|
Yes, this seems to be a completely javascript/client issue in the bulk api impl. | ||
| Comment by Andreas Nilsson [ 12/Mar/14 ] | ||
|
My setup is mongod 2.6.rc1 and shell 2.6.rc1. In the first case I start the shell with
In the second case with
ck should I expect the write concern validation to behave differently for legacy and command mode? | ||
| Comment by Scott Hernandez (Inactive) [ 12/Mar/14 ] | ||
|
Just to be clear you are talking about compatibility (shell write) mode not legacy mode with the bulk api. Calling getLastError treats w:0 == w:1 and will produce an error response. This is just an issue with the bulk api. The output you have above would for example happen if you connect to a 2.4 server. |