[SERVER-45775] responseTo does not match requestId for exhaust awaitable ismaster Created: 26/Jan/20 Updated: 29/Jan/20 Resolved: 29/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Matt Broadstone | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2020-02-10 | ||||||||
| Participants: | |||||||||
| Description |
|
My expectation was that if I sent an imaster request with the exhaustAllowed bit set and a requestId of 42, that subsequent responses would indicate a responseTo: 42 with the moreToCome bit set. Instead, I'm seeing that moreToCome is set, but the responseTo field changes on each response. My guess is that the exhaust support for awaitable ismaster is using an internal mechanism to simulate getMore requests. Is it possible to maintain the original requestId for the lifetime of the request in these cases? Otherwise, a driver will be required to develop custom logic only for this command. |
| Comments |
| Comment by Matt Broadstone [ 29/Jan/20 ] |
|
I spoke with redbeard0531 offline about this, closing as WONTFIX primarily because the existing approach is already used internally by the server, and maintains expectations of the legacy exhaust implementation. We'll circle back to this ticket in the future when driver's make a cursor spec to capture the rationale more completely. |
| Comment by Tess Avitabile (Inactive) [ 27/Jan/20 ] |
|
That's a good point. I wonder if we could make that change. My concern is how it would affect use of exhaust cursors for initial sync in multiversion sets. Our client code assumes that in the exhaust case, the next responseTo field will equal the previous response's requestId. We could preserve backwards compatibility by making theĀ requestId of the response equal to the requestId of the request for exhaust requests, instead of calling nextMessageId(). However, I'm not sure if this would have any negative consequences. redbeard0531, do you have any opinion on this? |
| Comment by Matt Broadstone [ 26/Jan/20 ] |
|
It looks like this is intentional, the id of the response is used as the requestId of the synthetic request. I wonder if this is expected behavior from a client's perspective. If the concept of an exhaust cursor is to issue a single command and receive multiple responses from the server, is a changing responseTo field a leak in that abstraction? |