Currently, we only pass the set of INLJ-eligible ready indexes to fromCachedJoinPlan and use that set of indexes to reconstruct single table predicate access paths. This is currently okay because the set of INLJ-eligible indexes (determined by indexIsValidForINLJ) is a strict superset of the set of CBR supported indexes (determined by isIndexScanSupported) and thus, we will always be able to find the index and reconstruct a plan.

However, if the 2 checks above diverge (e.g. CBR starts permitting sparse or partial filter indexes) then the STP access path may use this index but we will not find it during plan reconstruction since we are only looking at INLJ-eligible indexes. This would result in us hitting this tassert.

After SERVER-133479, we will have another join plan cache dependency during the usedFingerprint computation.

Furthermore, since sampling can yield and the join optimization layer and single table planner layers perform their own catalog reads, we end up with the case that the catalog state the join optimizer during its plan enumeration and join graph construction is different than the state of the catalog that the single table planners see. This results in bugs such as SERVER-135049. We should centralize this index read into one spot at the start of the join optimizer code path and pass the appropriate set to all the consumers.

Potential Solution:

1. First read the set of all ready indexes from the catalog for all the namespaces
2. Filter by INLJ-eligible indexes and pass to the appropriate consumers (INLJ enumeration code)
3. Thread the full set of indexes to the single table access layer rather letting the single table access layer performs its own set of catalog reads (here and here)