[EF Core 8] [Breaking Change] - error on working with explicit many-to-many relations with OnDelete.Restrict

[Gretam11]

Description

I'm currently migrating our project to the latest .NET and EF Core version (8), and I stumbled across the narrow, undocumented breaking change.
When you have many-to-many relation (Authors<->Books) with explicit intermediate table (BookAuthors), and you defined relations with OnDelete.Restrict action, then SaveChanges() throws an error if you try to modify list of linked entities (BookAuthors) through the root entity (Book).

Example

Entities:

public class Author
{
    public long Id { get; set; }
    public string Name { get; set; }
    public List<BookAuthor> BookAuthors { get; set; }
}

public class Book
{
    public long Id { get; set; }
    public string Name { get; set; }
    public List<BookAuthor> BookAuthors { get; set; }
}

public class BookAuthor
{
    public long BookId { get; set; }
    public long AuthorId { get; set; }
    public Book Book { get; set; }
    public Author Author { get; set; }
}

Model config:

modelBuilder.Entity<BookAuthor>().HasKey(x => new { x.AuthorId, x.BookId });

modelBuilder.Entity<BookAuthor>()
    .HasOne<Author>(x => x.Author)
    .WithMany(x => x.BookAuthors)
    .OnDelete(DeleteBehavior.Restrict);

modelBuilder.Entity<BookAuthor>()
    .HasOne<Book>(x => x.Book)
    .WithMany(x => x.BookAuthors)
    .OnDelete(DeleteBehavior.Restrict);

Actual operation:

var book = await dbContext.Books
                .Include(x => x.BookAuthors)
                .FirstAsync();

book.BookAuthors.RemoveAt(0);

await dbContext.SaveChangesAsync(); // error is thrown here

Exception:

Unhandled exception. System.InvalidOperationException: The property 'BookAuthor.BookId' is part of a key and so cannot be modified or marked as modified. To change the principal of an existing entity with an identifying foreign key,
 first delete the dependent and invoke 'SaveChanges', and then associate the dependent with the new principal.
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.NavigationFixer.ConditionallyNullForeignKeyProperties(InternalEntityEntry dependentEntry, InternalEntityEntry principalEntry, IForeignKey foreignKey)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.NavigationFixer.NavigationCollectionChanged(InternalEntityEntry entry, INavigationBase navigationBase, IEnumerable`1 added, IEnumerable`1 removed)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.InternalEntityEntryNotifier.NavigationCollectionChanged(InternalEntityEntry entry, INavigationBase navigationBase, IEnumerable`1 added, IEnumerable`1 removed)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.ChangeDetector.DetectNavigationChange(InternalEntityEntry entry, INavigationBase navigationBase)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.ChangeDetector.LocalDetectChanges(InternalEntityEntry entry)
   at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.ChangeDetector.DetectChanges(IStateManager stateManager)
   at Microsoft.EntityFrameworkCore.ChangeTracking.ChangeTracker.DetectChanges()
   at Microsoft.EntityFrameworkCore.DbContext.TryDetectChanges()
   at Microsoft.EntityFrameworkCore.DbContext.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
   at Program.Main() in D:\projects\EF8M2MUpdateError\EF8M2MUpdateError\Program.cs:line 109
   at Program.<Main>()

Versions information

EF Core version: 8.0.0
Database provider: ANY
Target framework: .NET 8.0

Additional information

Considering that normal one-to-many relations update with OnDelete.Restrict would also fail in such scenario (with clearer message though: The association between entity types 'Book' and 'Author' has been severed, but the relationship is either marked as required or is implicitly required), probably, the behavior above is correct, and it was wrongly working in EF Core v7. But I decided to create a ticket anyway, maybe it'll help someone who also stumbles across the same issue (since it's kind of a breaking change).

Reproduction repository

Here you can check the minimal project where this bug is reproduced (link).
You can also change package versions back to EF.* v7 to check that it wasn't the case in v7.

[ajcvickers]

Note for triage: everything seems to be by-design here.

[ADNewsom09]

We also ran into this same breaking issue on our 7 --> 8 upgrade

[jirikanda]

We found this problem after upgrading our project from EF Core 7 to EF Core 8.
Hope, the code mentioned by @Gretam11 is corrent in EF Core 7 and also corrent in EF Core 8. Even if it is not purely clean it became usual.

This breaking change (if by-design for triage) is not mentioned at Breaking changes in EF Core 8.0.

[jirikanda]

Why the code is correct? The same code is mentioned in the Severing a relationship chapter of the documentation.

Severing a relationship now works only for DeleteBehaviors Cascade and ClientCascade. For all other DeleteBehavios the change tracker throws an exception. The exceptions say we cannot change or modify the value of the (composed) primary key, but we are not trying to do it, we want to delete the entity representing the many-to-many relationship.

The only workaround I found is to registrer entities to be removed prior to removing them from the collection.

dbContext.RemoveRange(book.BookAuthors);
book.BookAuthors.Clear();

[ostracoder]

I also have this regression but only on join tables with payload.

It seems that just declaring the relationships as Cascade in the EF model is another possible workaround. You don't have to actually apply any change to the database tables. Ugly but it works.