[mesutk]

Fixes #39214

GetRelationalModel reads the RelationalModel runtime annotation and, when it is missing, the RelationalModelFactory annotation, with no synchronization between the two reads. When two threads make the first call for the same model at once, this can happen:

1. Thread B reads RelationalModel and gets null.
2. Thread A completes the first call: it stores RelationalModel and removes RelationalModelFactory.
3. Thread B reads RelationalModelFactory, gets null, and throws ModelNotFinalized, although the relational model is built.

This change reads RelationalModel again when the factory is missing, and only throws if it is still missing. Under the lock, the creating thread adds RelationalModel before it removes the factory, so a thread that finds the factory gone also finds the model. The fast path and the locked creation path are unchanged.

The race appears on the first concurrent use of a shared model. Examples are Migrator.HasPendingModelChanges on the cached design-time model when several contexts of one type migrate in parallel, and the first queries or SaveChanges calls on the runtime model. The same fix covers compiled models. A compiled model is a static instance shared by all service providers. Its factory is either generated into Initialize() (models generated for NativeAOT) or added by RelationalModelRuntimeInitializer, and in both cases it is consumed through this method.

The new test in RelationalModelTest uses a RuntimeModel subclass that overrides FindRuntimeAnnotation. Right after the outer call finds no RelationalModel, the override completes a nested first call, which reproduces the interleaving deterministically on one thread. Without the change the test fails with ModelNotFinalized, and with the change it passes. Local runs on macOS (arm64), rebased on main: Debug and Release builds with 0 warnings; EFCore.ApiBaseline.Tests passed (no public API change); EFCore.Relational.Tests 1520 passed, 1 skipped; EFCore.Sqlite.FunctionalTests 38228 passed, 286 skipped.

I filed #39214; its "Suggested fix" section proposes this change, and @AndriySvyryd approved the contribution there. This is a regression from EF 8, introduced with the lazy relational model in EF 9 (#33650). If you'd consider servicing it, I'm happy to open a port to release/10.0.

• I've read the guidelines for contributing and seen the walkthrough
• I've posted a comment on an issue with a detailed description of how I am planning to contribute and got approval from a member of the team
• The code builds and tests pass locally (also verified by our automated build checks)
• Commit messages follow this format:

        Summary of the changes
        - Detail 1
        - Detail 2

        Fixes #bugnumber

• Tests for the changes have been added (for bug fixes / features)
• Code follows the same patterns and style as existing code in this repo

[mesutk]

@dotnet-policy-service agree

[Copilot]

🟢 Approval recommended

The focused fix preserves existing paths and the regression test accurately exercises the reported race.

0 open findings

What changed in this PR

Fixes a first-use race in lazy relational-model initialization.

Changes:

• Re-reads the relational model before reporting an unfinalized model.
• Adds a deterministic regression test for the concurrent interleaving.

File	Description
src/​EFCore.Relational/​Extensions/​RelationalModelExtensions.cs	Handles factory removal caused by concurrent initialization.
test/​EFCore.Relational.Tests/​Metadata/​RelationalModelTest.cs	Tests the race deterministically.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[AndriySvyryd]

Thanks for your contribution!