I discovered this while looking into ecosystem timeouts on #24540. @AlexWaygood also found this while trying to bump our vendored typeshed.

When solving a constraint set that contains multiple typevars, we sometimes try to substitute a nested typevar in a constraint multiple times, leading to an endless expansion.

In #24540, we saw this with streamlit. Given constraints

Iterable[V_co] & int ≤ _T@list
ArrowStreamExportable & str ≤ _T@list
V_co = _T@list

Note that V_co is covariant, and V_co = _T@list, so we can substitute any lower bound of _T@list into Iterable in the first constraint. In particular, we can substitute V_co = ArrowStreamExportable & str, giving

Iterable[ArrowStreamExportable & str] & int ≤ _T@list

That gives us another lower bound for _T@list, which we can substitute again

Iterable[Iterable[ArrowStreamExportable & str] & int] & int ≤ _T@list

and on and on!

To catch this, we now keep track of when a new derived constraint comes from a substitution. When walking paths in a constraint set, we do not add a derived constraint if we already have some other constraint on the path that came from the same substitution. In the streamlit example, that means we will only substitute for V_co in the first constraint at most once per BDD path.