PR 5206 fixed a problem where a deletion of acp agent would leave settings with orphaned data that would create unexpected behaviors. The PR prevents the problem from happening in the future but does not solve the problem for users that already have this problem. There the correct approach is a data repair that runs at startup. We have schema migrations for settings data but this issue isn't related to a schema migration, it is produced by a logic error. Note these are not DB issues -- they are issues in settings data stored in file system. Options: 1. Add migration system that runs at startup and applies one time data repairs where needed because we are likely going to have more of these given the number of settings related bugs I am finding. 2. Don't use a migration system. Always run all data repair scripts on startup with assumption that targeted fixes will be a few ms and we wont have many enough to worry about. 3. Use schema system and add versions even when there are no schema changes as a place to put the migrations. (This seems yucky but for the sake of completeness...) Kindly vote on it.

It sounds like a migration to me. I’d probably go for 3, even; I don’t know that it’s necessarily yucky, one could argue that the contract includes behavior 😇 , but no strong feelings either way

@modern-fireman-99755 What is your view on this one?

option 3 seems the less invasive or?

I think #3 will be confusing to us later as we'll see a bunch of schema change bumps with nothing actually having changed. If we want to be minimally invasive in terms of adding new systems, I think that would be #2. But eager to take direction from OSS maintainers and contributors on this.

I'd say going for #3 now, and create an issue for #1 for long term. That way we can get to a good state right away through #3, and get a migration system we like without the time pressure of fixing current setttings.