[SERVER-79175] Improve AutoStatsTracker usage in distinct and find commands Created: 21/Jul/23  Updated: 14/Dec/23  Resolved: 14/Dec/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jordi Olivares Provencio Assignee: Backlog - Catalog and Routing
Resolution: Duplicate Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-83174 AutoStatsTracker contract is unclear Backlog
Related
related to SERVER-84200 Complete TODO after SERVER-83174 (pre... Backlog
is related to SERVER-83657 Top::LockType::NotLocked reported whe... Open
is related to SERVER-83174 AutoStatsTracker contract is unclear Backlog
Assigned Teams:
Catalog and Routing
Sprint: Execution EMEA Team 2023-09-04, Execution EMEA Team 2023-09-18, Execution EMEA Team 2023-10-02, Execution EMEA Team 2023-10-16, CAR Team 2023-11-13, CAR Team 2023-11-27
Participants:

 Description   

With the move towards using acquisitions we discovered that a lot of our current testing infrastructure relies on entries being present in the profiling collection. Previously the necessary setup was performed within the AutoGetCollectionForReadCommand family of classes.

With the move towards shard role acquisitions, we had to resort to manually setting it up in the commands, resulting in very large chunks of code that are replicated on other integrations.

This ticket is about finding a better way to encapsulate this pattern.



 Comments   
Comment by Haley Connelly [ 07/Dec/23 ]

Passing this ticket to the backlog so it can be re-prioritized after the investigation. 

Investigation Main Takeaway:
The code is not complex comparatively  to other usage of AutoStatsTracker. We could simply remove the TODOs and work toward a future where we redesign / rethink how we record operation metrics.

  • SERVER-83174 AutoStatsTracker contract is unclear: We probably should re-asses the use of the AutoStatsTracker throughout the codebase and figure out a more systematic way to use it.
  • The profiler captures error messages when a command fails. We can't just remove testing logic that tests for transient StaleConfig exceptions and simplify the code to use AutoStatsTracker after the lock acquisition, or we risk not catching non-transient errors we would have otherwise caught.
Comment by Haley Connelly [ 02/Nov/23 ]

 current testing infrastructure relies on entries being present in the profiling collection.

For example, safe_secondary_reads_drop_recreate.js relies on the find operation to utilize the AutoStatsTracker so the profiler logs when a StaleConfig is thrown for a successful find operation.

Generated at Thu Feb 08 06:40:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.