Repository navigation
fix(protocols): auto-registration's abstract check misreads Protocol subclasses on GraalPy #2784
Description
What
On GraalPy 25.4, the experimental leg fails tests/protocols/test_protocol_registry_2763_unit.py::AutoRegistrationTests::test_an_abstract_subclass_is_skipped at its first assertion. inspect.isabstract(type('W2763Bare', (Protocol,), {...})) returns False. See #2483's run: 1 failed, 228 passed. That PR only touches the changelog, so the failure comes from main.
Protocol.__init_subclass__ decides whether a class auto-registers with that same inspect.isabstract(cls) check, which runs before class creation finishes. I infer, but have not checked, that GraalPy also registers abstract subclasses by name.
Proposal
Reproduce on GraalPy and establish the mechanism. Then replace the check with one that does not depend on the interpreter's abstract flag, and give the test an oracle that works on every interpreter.
Additional context
The leg never blocks (#1660), and every main GraalPy run since #2770 was stopped as superseded. That is why this did not show up until a full run.
Activity
JarryShaw commentedon Nov 5, 2026
Confirmed on
main. Thef3825182fExperimental run is the firstmainGraalPy run to finish since #2770, and it fails the same single test:test_an_abstract_subclass_is_skipped, 1 failed and 228 passed. The CI-reports thread posted it as a warning. #2483's leg failed on the same id and nothing else.JarryShaw commentedon Nov 5, 2026
Correction. The inference in the body was wrong. Measured on GraalPy 25.4.4, an abstract
Protocolsubclass is not registered. The actual defect: the hook'sinspect.isabstractcall reads__flags__mid-creation, and GraalPy then freezes the flag, so the class reads as concrete afterwards. The fix is up as #2785.fix(protocols): decide auto-registration's abstractness without the i…
JarryShaw commentedon Nov 5, 2026
Confirmed on
main: the Experimental run atf312f92f3, with #2785 in, passed every job with no warning. GraalPy is green again.