Cleaning Previous Run Leftovers (e.g. Containers)

[areller]

I propose a simple solutions for cleaning leftovers artifacts from previous runs, in the case where the process did not exit gracefully.

Example: When I run the ApplicationHost after it did not exit gracefully last time, I run into this error

Apart from having cosmetical implications, it could create side effects for the user, since in normal use, his containers restarts every time he launches the application host and their state is deleted.

[davidfowl]

This is something I've been meaning to tackle. Thanks for jumping in! I have a couple of problems with the current implementation.

• It's currently only handling containers (it should also handle processes that were created on the last run)
• The .m8s folder being created next makes me a little uneasy but maybe it's fine. It's something that would need to be added to people's gitignore files since it's per run state (tied to the machine)
• Should the storage just be a serialized version of the service at that point in time? It feels like you could just serialize each of the Service objects at different points in time instead of having a different format.
• Much like the EventPipeDiagnosticsRunner I wonder if this couldn't be a cross cutting concern that runs first and subscribes to ReplicaEvents, persists the state (maybe into a sqllite db or file like you have) and cleans the previous state up on startup.

Example: When I run the ApplicationHost after it did not exit gracefully last time, I run into this error

Did you run it under the debugger and detach? Thats how this ends up happening for me 99% of the time. Regardless it should be fixed.

[areller]

1. I'll add support for processes as well
2. I'll think about it, but I'm not sure if there is a way around it. At first I thought about creating it in the user's temp folder, but what if there are multiple distinct instances of m8s running?
   3 and 4. I can subscribe to ReplicaEvents and serialize them, to clean them up on the next run. I really like that idea.

I actually noticed it when I ran the ApplicationHost inside Rider. It doesn't close processes gracefully.

[davidfowl]

I'll think about it, but I'm not sure if there is a way around it. At first I thought about creating it in the user's temp folder, but what if there are multiple distinct instances of m8s running?

Yea I don't have a great solution either. Maybe it's time to write a daemon process but lets keep this simple for now.

3 and 4. I can subscribe to ReplicaEvents and serialize them, to clean them up on the next run. I really like that idea.

👍 I'm going to look into making some base classes for IApplicationProcessor as some patterns are shaking out as more scenarios come online.

[areller]

@davidfowl This is still WIP, but how do you like my latest commit?
I have a class that consumes ReplicaEvents
Every class that can instantiate a replica, has to implement IReplicaInstantiator that tells how that replica is serialized/deserialized and how stale replicas (leftover from previous run) are dealt with.

👍 I'm going to look into making some base classes for IApplicationProcessor as some patterns are shaking out as more scenarios come online.

After you're done, I could edit ReplicaStateRecorder to fit the new pattern.

[davidfowl]

@aller are you still around? I'm back 😄 Will get back to this soon.

[davidfowl]

This feature is sorely needed and this project has moved development to https://github.com/dotnet/tye. Would you be willing to move this PR here @areller ?

[areller]

@davidfowl I tried to move the files and change namespaces but it seems that there are more substantial code changes in the new repo.
I'll have a closer look in the evening or tomorrow.

[areller]

dotnet/tye#155