There seems to be some imports percolating through the community which are causing some users to disconnect (? it's hard to tell what exactly is happening, some describe it as a "crash") when logging in with WeakAuras enabled, effectively turning the addon into a pumpkin.

Normally, we would say that fixing problems with custom code isn't our purview - Just Don't Use Custom Code™️ and the like. But, in this case i think we should think about ways to at least provide an escape hatch for users to recover from this without needing to either start over from scratch or understand the savedvariables format well enough to perform surgery.

So, what about some sort of recovery mode? Create a switch that a user could (with some effort) flip that would cause WeakAuras to "boot" into a mode where the user can edit (or at least delete) auras, but the data is never used to instantiate active regions (and especially not run any custom code).

"But rivers, how would we even accomplish that?"

The idea i had which prompted this ticket was to add an optional dependency to WeakAuras (call it WeakAurasSafeMode or some such), disabled by default, which WeakAuras would check for upon first load. During safe mode, normal login process is suspended (easy enough) and the user is alerted that WeakAuras is "powered down". User can open options (this seems hard) and edit their data to fix problems that can't be fixed in "live" mode. once the user is done, they could disable safe mode and reload their ui to resume normal play.

I guess the first thing we need is a test cases of problematic settings. And yeah there seems to be both genuine crashes and timeout(?) disconnects. So that we can figure out what exactly leads to the problems and what exactly we would need to avoid so that the user can delete auras. I suspect if we have examples we can probably optimize things so that there's no disconnect.

An optional dependency sounds clever, though.
If we can get away with instructing users to delete auras via WeakAuras.KillItWithFire then I think the task becomes more mangeable. We could then disable pretty much everything in WA, and directly modify WeakAurasSaved.

So the simplest solution that could work is to add a check to IsLibsOkay() for WeakAurasSafeMode, and if enabled do nothing. And in WeakAurasSafeMode provide an interface either a console like above or a simple GUI implementation, in any case strictly run onto of WeakAurasSaved.

That sounds like a simple solution, though I'm not sure how big the problem is.

ok, so, how about this:

we publish an addon (named after whatever our favorite bikeshed is) which WeakAuras has as an optional "anti" dependency - if weakauras detects this addon is loaded, it refuses to operate in the same manner it does so if it's missing any "true" dependencies (crucially, savedvariables are still loaded into the game at this point). That addon (which isn't normally installed along with weakauras) has a relatively simple tree view browser which allows users to, at minimum, delete from saved variables any aura (possibly along with its child auras if it's a group). When the user is done with their surgery, they click a button which disables the surgery addon and reloads the UI, which will then cause WeakAuras to resume normal operations (just, with some intentional memory loss).

i think that strikes a good balance of convenience and utility for our users. If a user asks how to remove an aura without starting WA (we do get this question sometimes), we have a "magic" solution conveniently available, but most users won't be bothered by it.

Yes, that what I had in mind too. Don't create a safe mode, but a do nothing mode. And use an entirely different much simpler method to adjust just WeakAurasSaved.

That sounds like a much simpler to implement solution that would help.

Though I'm still interested in the settings of users with strange problems, there might be something to improve