[SERVER-61621] Check `shardCollection` config namespaces validity on the router Created: 19/Nov/21 Updated: 27/Oct/23 Resolved: 02/Dec/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 5.2.0, 5.1.0, 5.0.4 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Pierlauro Sciarelli | Assignee: | [DO NOT USE] Backlog - Sharding EMEA |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding EMEA
|
| Participants: |
| Description |
|
Currently, in case a user issues a command to shard a config collection, it happens the following:
Since it is not correct to instantiate DDL coordinator for config namespaces (other than config.sessions), the check should be moved directly on the router. Similarly to the way the rename collection command checks for invalid namespaces. |
| Comments |
| Comment by Pierlauro Sciarelli [ 29/Nov/21 ] |
|
This is the check that should be done on the router: I was not suggesting to use the isValid check, I pointed to the rename code just to show an example of how we reject the operation on the router instead of instantiating coordinators in case the options are not valid. It's an optimization because we should never instantiate coordinators with invalid options, but the current behaviour is not harmful. |
| Comment by Sergi Mateo Bellido [ 25/Nov/21 ] |
|
pierlauro.sciarelli: adding an isValid check on the router won't prevent the command to reach the primary shard if the operation is on a config database. Moreover, we believe that it is not a correctness issue but an optimization. Did we miss something? |