Fix duplicate entity tracking error when re-attaching detached entities with client-generated keys

[Copilot]

When entities with client-generated keys (Guid PKs, InMemory provider) are manually detached and re-attached, setting the state on the original entry fails with "Duplicate InternalEntityEntry" if the entity was already re-tracked through navigation fixup.

var fooEntry = context.Foos.Add(foo);
var barEntry = context.Bars.Add(bar);

// Detach entities
fooEntry.State = EntityState.Detached;
barEntry.State = EntityState.Detached;

// Re-attach parent
fooEntry.State = EntityState.Added;

// Restore navigation and detect changes - this creates a new entry for bar
bar.Foo = foo;
fooEntry.DetectChanges();

// This now throws: "Duplicate InternalEntityEntry"
barEntry.State = EntityState.Added;

Changes

• InternalEntityEntry.OnStateChanging: Check if entity is already tracked by a different entry before calling StartTracking. If so, forward the state change to the active entry instead of failing.
• Test coverage: Added Can_reattach_graph_with_client_generated_keys to validate the scenario.

The fix allows user code that manually manages entity state to work correctly when EF Core has already re-tracked entities through navigation fixup.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>InMemoryProvider causing 'The instance of entity type 'x' cannot be tracked(...)' when manually re-attaching graph</issue_title>
<issue_description>### Bug description

I'm building an extension for EF Core and at some point, I need to detach entities from the db context and then re-attach them manually.
This works, but when migrating to this extension in my existing code base (in which I have hundereds of tests against the in-memory provider), I got a lot of test cases failed at what seemed to be random (e.g. sometimes simply not adding unrelated entity to the db context instance would make the test green). Turns out that the tests fails only when entities are returned from change tracker in a specific order. I know there is no inherent order to those, but below is specific example where there is exception.

Changing pretty much anything (the order in which the entities are added to the db context instance or the order in which they are re-attached) makes the problem go away.

The issue happens only when using the InMemoryProvider (or, to be more specific - doesn't happen when using Sql server provider).

Your code

using Microsoft.EntityFrameworkCore;

namespace EFCoreDeuplicateEntity.Tests;

public class Foo
{
    private Foo()
    {
    }

    public Foo(string name)
    {
        Name = name;
    }

    public int Id { get; set; }

    public string Name { get; set; }

    public ICollection<Bar> Bars { get; set; } = new HashSet<Bar>();
}

public class Bar
{
    private Bar()
    {

    }

    public Bar(string name, Foo foo)
    {
        Name = name;
        Foo = foo;
    }

    public int Id { get; set; }

    public string Name { get; set; }

    public Foo Foo { get; set; }

    public int FooId { get; set; }

    public Bar? RelatedBar { get; set; }

    public int? RelatedBarId { get; set; }
}

public class FooContext : DbContext
{
    public DbSet<Foo> Foos => Set<Foo>();
    public DbSet<Bar> Bars => Set<Bar>();

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseInMemoryDatabase("TestDb");
    }
}

[TestClass]
public class Test
{
    [TestMethod]
    public void Test_DuplicateEntity()
    {
        using var context = new FooContext();
        var foo = new Foo("Foo1");
        var bar1 = new Bar("Bar1", foo);
        var bar2 = new Bar("Bar2", foo);
        bar2.RelatedBar = bar1;
        
        var fooEntry = context.Foos.Add(foo);
        var bar1Entry = context.Bars.Add(bar1);
        var bar2Entry = context.Bars.Add(bar2);

        fooEntry.State = EntityState.Detached;
        bar1Entry.State = EntityState.Detached;
        bar2Entry.State = EntityState.Detached;

        // bar2.RelatedBar is null, since EF removes the navigation when detaching entities in 'Added' state

        fooEntry.State = EntityState.Added;
        fooEntry.DetectChanges();

        bar2Entry.State = EntityState.Added;
        bar2.RelatedBar = bar1; // Manually restore the navigation
        bar2Entry.DetectChanges();

        // Line below throws:
        // The instance of entity type 'Bar' cannot be tracked because another instance with the same key value for {'Id'} is already being tracked.
        // When attaching existing entities, ensure that only one entity instance with a given key value is attached
        bar1Entry.State = EntityState.Added;
        bar1Entry.DetectChanges();
    }
}

Stack traces

Verbose output

EF Core version

9.0.9

Database provider

Microsoft.EntityFrameworkCore.InMemory

Target framework

.net 8.0

Operating system

No response

IDE

No response</issue_description>

<agent_instructions>Start by creating a test based on the SqlServer repro in the last comment</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@roji Am not quite sure how the above could be specific to InMemory, as it seems to be doing pure change tracking operations - any thoughts @AndriySvyryd?

If it really is specific to InMemory in some way, then note that we're no longer investing in that provider and discourage its use by users - we're therefore be unlikely to investigate and fix this.</comment_new>
<comment_new>@roji

My bet is that it has somehting to do with the fact that the InMemoryProvider generates the PK's when the entities are added to the change tracker (and not upon save changes).

If that's the case, you should be able to reproduce this on SQL Server/SQLite by having Guid PKs - EF generates those on the client by default as well. If you can show that happening on those providers that would make this issue more important.</comment_new>

• Fixes InMemoryProvider causing 'The instance of entity type 'x' cannot be tracked(...)' when manually re-attaching graph #36921

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull Request Overview

This PR fixes a potential issue with entity tracking when reattaching graphs with client-generated keys. The fix prevents duplicate tracking errors when an entity is detached and then re-tracked via navigation fixup (DetectChanges) before manually setting its state.

Key Changes:

• Added detection logic in InternalEntityEntry.OnStateChanging to check if an entity is already tracked by a different entry
• Added a regression test demonstrating the scenario where this issue could occur

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/EFCore/ChangeTracking/Internal/InternalEntityEntry.cs	Added logic to detect and handle already-tracked entities during state transitions from Detached
test/EFCore.Tests/ChangeTracking/GraphTrackingTest.cs	Added test case for reattaching graphs with client-generated keys

[Copilot]

The early return at line 216 bypasses the rest of the OnStateChanging flow, which means the subsequent call to StateManager.StartTracking(this) at line 219 is skipped. However, this also means that OnStateChanged (line 229) will never be called for this stale entry. This could result in state change events not being fired, change counters not being updated, and potentially other side effects. Consider whether OnStateChanged or other cleanup should be called before the early return, or if the current entry needs different handling (e.g., should this entry be marked as detached or disposed?).

Suggested change

	existingEntry.SetEntityState(newState);
	existingEntry.SetEntityState(newState);
	OnStateChanged(newState);

[Copilot]

The nullable reference type annotations are missing for reference type properties. According to the coding guidelines, nullable reference types should be used. These properties should either be marked as nullable (e.g., public string? Name { get; set; }) or initialized to prevent potential null reference warnings.

Suggested change

	public string Name { get; set; }
	public string Name { get; set; } = string.Empty;

[Copilot]

The nullable reference type annotations are missing for reference type properties. According to the coding guidelines, nullable reference types should be used. These properties should either be marked as nullable (e.g., public string? Name { get; set; }) or initialized to prevent potential null reference warnings.

Suggested change

	public BarGuid RelatedBar { get; set; }
	public BarGuid? RelatedBar { get; set; }