Remove assertion for verbose result #1835
Conversation
| // Note: Previously, assertTrue(verboseResultsSetting) was used here because the server was not supposed | ||
| // to return successful operation results in the cursor when verboseResultsSetting is false. | ||
| // Due to server bug SERVER-113344, these unexpected results must be ignored until we stop supporting server | ||
| // versions with this bug. When that happens, restore assertTrue(verboseResultsSetting) here. |
There was a problem hiding this comment.
Let's leave a TODO-<JAVA ticket ID> tag here, and create a corresponding ticket, which is linked as "blocked by" / "depends on" (not sure what relations we have) to the aforementioned server ticket.
There was a problem hiding this comment.
We may have to keep this code for some time (years) - while we wait for servers to be updated.
There was a problem hiding this comment.
Added a TODO-JAVA-6002 tag and created a follow-up ticket to restore the assertion.
I linked it to the server ticket as blocked by. As @rozza mentioned, even after the server fix lands it may not be backported to 8.x, so we’ll likely re-enable the assertion once our minimum supported server version includes the fix (or gate it conditionally on server version).
| writeModelIndex, | ||
| new ConcreteClientUpdateResult( | ||
| individualOperationResponse.getInt32("n").getValue(), | ||
| individualOperationResponse.getInt32("nModified", new BsonInt32(0)).getValue(), |
There was a problem hiding this comment.
It looks to me that this change, coming from #1823, should have also had a corresponding JAVA ticket describing that it is to be rolled back once https://jira.mongodb.org/browse/SERVER-113026 (it is not the same as the aforementioned SERVER-113344) is fixed and no version where the bug is present is supported. The TODO-<Jira ticket ID> tag will be needed here as well, to point to the place that needs to be changed.
There was a problem hiding this comment.
Added the TODO tag and created the corresponding ticket TODO-JAVA-6005 . I also added a unit test for the behavior introduced in that PR.
| fail(writeModel.getClass().toString()); | ||
| } | ||
| if (okFieldValue == 1) { | ||
| collectSuccessfulIndividualOperationResult( |
There was a problem hiding this comment.
The TODO comments made the method larger and harder to follow. To keep the control flow maintainable, I moved one of the logical branches into a separate method. This keeps the main if/else structure concise and makes each path easier to identify and understand.
…tBulkWriteOperationTest.java Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
3 participants
This PR addresses server bug SERVER-113344 by modifying the client-side bulk write operation handling to work around unexpected server responses.
The changes:
JAVA-6001
JAVA-5986