[CDRIVER-2418] mongoc_cmd_parts_assemble() may add readConcern afterClusterTime to generic commands Created: 07/Dec/17 Updated: 28/Oct/23 Resolved: 08/Dec/17 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | libmongoc |
| Affects Version/s: | None |
| Fix Version/s: | 1.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jeremy Mikola | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MongoDB Enterprise 3.6.0 |
||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
While running something similar to test #2 in the Driver Sessions spec, I received a server error ("afterClusterTime is not allowed for this command") on the second of two ping commands sent with the same explicit client session. This was using the generic mongoc_client_command_with_opts() command runner with the "sessionId" option. According to the Causal Consistency spec:
Looking at mongoc_cmd_parts_assemble(), I believe that we're entering this condition. libmongoc is only checking that the command is not a getMore before deciding to add a read concern with afterClusterTime. I think it may need to track whether the command supports a read concern (similar to is_write_command on mongoc_cmd_parts_t). |
| Comments |
| Comment by Githook User [ 11/Dec/17 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |
| Comment by Githook User [ 08/Dec/17 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |
| Comment by Bernie Hackett [ 07/Dec/17 ] |
|
The problem isn't commands not supporting readConcern. The problem is commands not supporting afterClusterTime. Happily, the commands that don't support afterClusterTime aren't on this list: The upshot is, only certain commands support readConcern (those in the above mentioned list) and only those commands should have afterClusterTime added to them. The command helper shouldn't be implicitly adding readConcern (though the application should be able to explicitly add one and accept the consequences): Fix the readConcern problem and you fix the afterClusterTime problem. |
| Comment by Jeremy Mikola [ 07/Dec/17 ] |
|
The first option seems preferable, as mongoc_client_command_with_opts() should not be add cluster time per the driver sessions spec. While that function avoids applying defaults from mongoc_client_t (e.g. read concern, write concern), it does respect such options if passed through opts. I suppose even in the case where a user provides a read concern option, we still wouldn't want to add cluster time to it and just use the read concern option value as-is. |
| Comment by A. Jesse Jiryu Davis [ 07/Dec/17 ] |
|
Two options. 1. Decide based on the function you call whether to add readConcern: afterClusterTime. mongoc_client_command_with_opts will not add readConcern: afterClusterTime, whereas mongoc_client_read_command_with_opts, mongoc_client_write_command_with_opts, and mongoc_client_read_write_command_with_opts will add readConcern: afterClusterTime. All the other functions that support sessions will add readConcern: afterClusterTime. For example, mongoc_collection_aggregate, mongoc_collection_insert_one, etc. etc. 2. (I hope we can avoid this.) Blacklist known commands that don't accept readConcern, like "ping" and so on. It doesn't matter which function you call, only the command name matters. |