Capture events in constructor configuration when using context pooling

[KenBrannigan]

I have a ASP.NET Core 3.0 application using .NET Core 3.0 and EF Core 3.0. I am using AddDbContextPool to register my DbContext:

services.AddDbContextPool<IMyDbContext, MyDbContext>(
            optionsAction: options => options.UseSqlServer(
                connectionString: Configuration.GetConnectionString("MyDatabase"))
);

In my DbContext constructor, I attach to two events of the ChangeTracker:

public MyDbContext(DbContextOptions<MyDbContext> options)
            : base(options)
{
            // Attach to our important events
            ChangeTracker.StateChanged += ChangeTracker_StateChanged;
            ChangeTracker.Tracked += ChangeTracker_Tracked;
}

The first time I run the application the events are fired when I add items to my context. Once the page is done loading I make another request but none of my events fire this time when adding items to my context. It seems when it pulls a context out of the pool it no longer has the event handlers registered.

I have no issues when I use regular AddDbContext. Is this expected behavior or is there a different way I should register my event handlers?

[AndriySvyryd]

@KenBrannigan This is by design. Each time you return a MyDbContext instance from the pool it gets all its state removed, so these events should be added whenever the context is requested from the pool. #17086 would make this simpler

[ajcvickers]

@AndriySvyryd for other things that can be set in the constructor we make an effort to reset the the values that were set after the constructor finished. We should discuss whether or not to try to do this here.

[ajcvickers]

We discussed this in triage and decided that rather than continue along the path we have been on with capturing and resetting constructor configuration, we should implement #17086 and direct people to use that for per-request configuration of the instance.

We may then choose to stop capturing configuration at all. We could even "Reset" the context after it has been constructed.

[AndriySvyryd]

We discussed it in triage again and decided to go back to resetting the state to what was captured after the constructor.