Fix StackOverflowError from self-referential supertype in Python type mapping#7240
Merged
knutwannheden merged 1 commit intomainfrom Apr 2, 2026
Merged
Conversation
…pattern
The pattern `class Pair(namedtuple('Pair', ...))` causes ty-types to emit
two classLiteral descriptors with the same FQN but different type_ids. The
classLiteral handler used _create_class_type() which deduplicates by FQN,
collapsing both into the same JavaType.Class object. When the outer class
sets its supertype to the inner namedtuple type, it ends up pointing to
itself — a self-loop that causes StackOverflowError in Java's
TypeUtils.isAssignableTo().
Fix by creating a fresh JavaType.Class per classLiteral type_id instead of
deduplicating by FQN. The _type_id_cache in _resolve_type() already handles
deduplication by type_id, and ty-types type_ids are the correct source of
truth for type identity.
knutwannheden
force-pushed
the
fix-stackoverflowerror-in-typeutils.isassignableto
branch
from
03a5551 to
67764bf
Compare
knutwannheden
changed the title
knutwannheden
deleted the
fix-stackoverflowerror-in-typeutils.isassignableto
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Flagship recipe run alerts on app.moderne.io revealed ~7,400 per-file
StackOverflowErrors inTypeUtils.isAssignableTo(), all from 3 variants ofimportlib_metadata/__init__.pyin Netflix/metaflow. The root cause is theclass Pair(namedtuple('Pair', ...))pattern inimportlib_metadata._collections.namedtuple('Pair', ...)generates a class also namedPair, so ty-types emits twoclassLiteraldescriptors with the same FQN but different type_ids. TheclassLiteralhandler used_create_class_type()which deduplicates by FQN, collapsing both into the sameJavaType.Classobject. When the outer class sets its supertype to the inner namedtuple type, it ends up pointing to itself —Pair._supertype = Pair.Summary
_create_class_type()in theclassLiteralhandlerJavaType.ClassperclassLiteraltype_id instead — ty-types type_ids are the correct source of truth for type identity_type_id_cachein_resolve_type()already handles deduplication by type_idTest plan
test_namedtuple_subclass_no_self_supertype: constructs the exact namedtuple pattern (two classLiterals, same FQN, one is supertype of the other), verifies no self-referential supertypemetaflow/_vendor/importlib_metadata/__init__.py—Pairnow has two distinctJavaType.Classobjects, no cyclestest_type_attribution.pypasses (101 tests, no regressions)