Investigate router-driven StaleConfig handling for change-stream updateLookup (CollectionRouter onException + injected CRI)

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Query Execution
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Summary

      The single-document lookup currently handles StaleConfig with a bespoke catch -> onStaleCollectionVersion -> reset acquisition (yields the lock) -> drop memoized CRI -> kNotHandled -> fallback re-routes. This is correct and CAR-accepted. Investigate folding it into CollectionRouter for a cleaner shared mechanism.

      Proposed direction

      Wrap the lookup in routeWithRoutingContext(callback, onException):

      return router.routeWithRoutingContext([&](routingCtx){
          auto d = eligibility.check(routingCtx.getCri(nss), documentKey);  // CRI injected, not re-fetched
          if (!d.isLocal()) return kNotHandled;
          ScopedSetShardRole scope(...); acquisition = acquirer.acquireCollection(nss); runExecutor();
      }, /*onException*/ [&]{ acquisition.reset(); });                       // yield lock; router drives refresh/retry
      

      Benefits: the router owns refresh/retry; a single CRI is shared by both the router and LocalLookupEligibility (no double CatalogCache fetch).

      Likely CollectionRouter API extensions (CAR review)

      • An onException/onSuccess hook on route/routeWithRoutingContext to yield then reacquire locks.
      • Avoid recreating RoutingContext/NssRoutingInfoMap on every per-document call (cache across invocations – this is per-document, not per-query).

            Assignee:
            Denis Grebennicov
            Reporter:
            Denis Grebennicov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: