It looks like EnsureConnectionIsClosed(); is rarely/never being called when executing the migration (and it succeeds). In the FluentMigrator code, I can only find references in GenericProcessorBase.Dispose() and the Firebird processor.
I'm using the DI example for in-process migrations from the quickstart guide. And after runner.MigrateUp(); (example), the database is left open with a "AWAITING COMMAND" connection on the SqlServer runner.
The runner should've been destroyed when the DI container/scope gets destroyed.
Thanks. The reason I noticed this is because I'm trying to setup a process where I create a test database (using an xUnit fixture) and then also drop the database at the end (after all tests run). But the teardown wasn't working (deleting the test database) because it looks like FM runner/processor is leaving a connection open.
I'm taking a guess as to where the bug might be in the FM code. I could be way off the mark.
I've refactored enough to show that it happens with the PostgreSQL migrator as well.
Thank you, this will definitely help.
@tgharold Wow! Thanks for putting all this together, especially the docker-compose stuff. Are you familiar with Docker Tools for Visual Studio? I haven't really used it, but I guess it should let you define a special .dcproj (docker compose project type) and then the debugger will automate some of that stuff you put in the readme.md
However, any csproj can also add a <DockerTargetOS> element and it should work - see my example here: https://github.com/jzabroski/ImplicitReferencesFailTransitively/blob/master/Sample/WebApi/WebApi.csproj
@tgharold I am going to try to dive deeper into this behavior, perhaps this weekend.