[SERVER-65921] Annotate config server access originating from the config server functionality Created: 25/Apr/22 Updated: 09/May/22 Resolved: 09/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Andrew Shuvalov (Inactive) | Assignee: | Andrew Shuvalov (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | sharding-nyc-subteam2, sharding-nyc-subteam2-catalog-poc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Sharding 2022-05-02, Sharding NYC 2022-05-16 |
| Participants: | |
| Story Points: | 3 |
| Description |
|
Our main source of test failures is the inability to easily distinguish between requests coming to the config server from the shard functionality or the config functionality. In the dedicated configuration this is not a problem as everything coming from the direct client is coming from the config server. We should annotate the op context when it is originated from the config server functionality. This is particularly easy to test by adding a temporary invariant to assert that this boolean flag is set whenever a direct client is used, and run all regular tests with catalog client feature turned off. |