[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:
Related
is related to DRIVERS-722 Cursor spec Backlog
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?

Generated at Thu Feb 08 05:09:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.