Repository navigation
fix: release the type registry when a model version is selected - #191
Merged
ehennestad merged 5 commits intoSep 11, 2026
Merged
ehennestad merged 5 commits into
ehennestad merged 5 commits into
Conversation
ehennestad
added this pull request to stack #189
September 11, 2026 07:06
Contributor
Contributor
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## instance-library-test-fixture #191 +/- ##
=================================================================
- Coverage 80.67% 80.14% -0.53%
=================================================================
Files 423 423
Lines 4387 4392 +5
=================================================================
- Hits 3539 3520 -19
- Misses 848 872 +24 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ehennestad
force-pushed
the
release-type-registry-on-version-switch
branch
3 times, most recently
from
September 11, 2026 10:28
5076d42 to
66e852c
Compare
ehennestad
force-pushed
the
release-type-registry-on-version-switch
branch
from
September 11, 2026 12:01
66e852c to
ffdeee7
Compare
A model version is selected by putting its generated classes on the search path, and MATLAB reads a class definition from the path again only once nothing holds an instance of it. The type registry holds enumeration values of the version it was built for, and nothing released it on a switch, so it kept the previous version's Types enumeration in memory. The instance library, rebuilt on the switch, then resolved the selected version's instances against that enumeration, and every type the two versions do not share came out untyped: 2827 of 17096 on a switch to v3.0, with a warning naming them, six times per CI run. selectModelVersion now releases the registry after the path change, before the pause that lets the reload happen and before the library resolves types. The registry's next use rebuilds it. The library itself pins nothing, as it records type names as strings, and neither does an instance of a type class; with the registry released the enumeration reloads on the switch, the library resolves every instance, and the warning does not fire anywhere in the suite. The assertion that a version switch leaves no instance untyped, which the pin had forced out of the integration test, is back. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The test built the registry for whatever version the session was on and switched to v3.0, checking for the types that tell v3.0 apart from latest. On a session already on v3.0, or on v4.0, which shares those types, both checks held before the switch had done anything, and the test passed without exercising the pin it exists for. It now selects latest first, and says why those two versions: latest declares AnatomicalAtlas, which v3.0 calls BrainAtlas. Should latest ever stop declaring it, the test says so rather than failing on the wrong thing. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The version the registry was built for was latest, which floats: the type that tells it apart from v3.0 today may be renamed in a later generation, and the guard on that would turn the test into a skip rather than a failure, quietly. The numbered versions are pinned to a schema commit and do not change, so the registry is now built for v5.0, where BrainAtlas became AnatomicalAtlas, and the switch is to v3.0. The precondition on v5.0 is asserted rather than assumed: a pinned enumeration that changed is something to hear about. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ehennestad
force-pushed
the
release-type-registry-on-version-switch
branch
from
September 11, 2026 12:17
ffdeee7 to
17efec2
Compare
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
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.
Stacked on #190. One fix to
selectModelVersion, so that selecting a model version within a session actually loads that version's classes.Why
A model version is selected by putting its generated classes on the search path. MATLAB reads a class definition from the path again only once nothing holds an instance of it. The type registry,
MetaTypeRegistry, holds enumeration values of the version it was built for, and nothing released it on a switch:getSingletonrebuilds it only when next asked. Left in place, it kept the previous version'sopenminds.enum.Typesin memory.selectModelVersionthen rebuilt the instance library (#184) against that pinned enumeration, so every type the two versions do not share came out untyped, with a warning that named them. On CI that was six warnings per run, from the classes that switch to v3.0 and v4.0, listing exactly the types those versions have andlatestdoes not:BrainAtlas,CommonCoordinateSpace,UBERONParcellationand the rest. Measured in one process, switching to v3.0 with the registry alive left 2,827 of 17,096 instances untyped.The instance library itself does not pin anything, since it records type names as strings, and neither does an ordinary instance of a type class; with only those alive the enumeration reloads on the switch.
What
MetaTypeRegistry.notifyModelVersionChangeddeletes the registry without rebuilding it, andselectModelVersioncalls it after the path change, before the pause that lets the reload happen and before the instance library resolves types against the reloaded classes. The next use of the registry rebuilds it, asgetSingletonalready does when it finds none.Measured in one process: switch with the registry alive, 2,827 untyped and the warning; release the registry, the v3.0 enumeration is what
meta.classreports in memory; rebuild the library, no warning and none untyped.Tests
SelectModelVersionTestis new: with the registry held, select v3.0 and check that theTypesenumeration in memory declaresBrainAtlasand notAnatomicalAtlas, which is what distinguishes v3.0's fromlatest's.InstanceLibraryIntegrationTestgets back the assertion the pin had forced out of it: after selecting a version, every instance of that version resolves to a type.Notes
On R2026a this removes the warning from every switch in the suite. On R2022a it still fires twice, on the first switch to another version in a session: there the enumeration was observed reloaded only after
selectModelVersionhad returned, later than the library resolves types against it, and the next switch is clean. Accepted for now.This does not make version switching robust in general; #169 covers that. Anything else that holds a
Typesvalue or an instance of a generated class across a switch still pins the previous version, and the warning on #184 now says so and what to do. What this fixes is that the toolbox itself was one of those holders.🤖 Generated with Claude Code