WA Options stuck on loading #4967
Comments
github-actions
bot
added
the
⏱ Awaiting Response
|
Hi I didn't forget about this, I was just avoiding thinking about it. Some notes:
All evidence seems to point to, 'normal execution was interrupted unexpectedly by Blizzard'. Normally, this only happens after 19 contiguous seconds of execution, which seems unlikely in this case, because a) we already chunk our execution to avoid exactly that problem, and b) I think we would get a lot of complaints if we were routinely freezing the game for 10+ seconds when any user opens options. There is one case where that 19 second timeout is conspicuously reduced. During combat the limit is something closer to 200 milliseconds. Normally, we refuse to open the options window during combat, but it turns out we don't stop thread execution if combat starts, so it's possible that a user with a) a lot of auras that use a lot of features that b) starts combat or gets put into combat by their party members while c) options is still building, could trigger a similar fail like this (though the exact stack traces are unlikely to be identical, due to the nature of script timeouts). |
nothing that we put into dynFrame threads is meant for in-combat execution anyways, so to avoid random unexpectedly short timeouts, pause execution if combat starts, and resume after combat ends. There's potential for WeakAuras to be 'broken' during that combat session (due to dynamic groups being Pause()'d), but we probably couldn't have unbroken it given that ResumeAllDynamicGroups is too costly to call during combat lockdown without risking a timeout. Fixes WeakAuras#4967 (or at least, reduces its likelihood)
nothing that we put into dynFrame threads is meant for in-combat execution anyways, so to avoid random unexpectedly short timeouts, pause execution if combat starts, and resume after combat ends. There's potential for WeakAuras to be 'broken' during that combat session (due to dynamic groups being Pause()'d), but we probably couldn't have unbroken it given that ResumeAllDynamicGroups is too costly to call during combat lockdown without risking a timeout. Fixes WeakAuras#4967 (or at least, reduces its likelihood)
nothing that we put into dynFrame threads is meant for in-combat execution anyways, so to avoid random unexpectedly short timeouts, pause execution if combat starts, and resume after combat ends. There's potential for WeakAuras to be 'broken' during that combat session (due to dynamic groups being Pause()'d), but we probably couldn't have unbroken it given that ResumeAllDynamicGroups is too costly to call during combat lockdown without risking a timeout. Fixes WeakAuras#4967 (or at least, reduces its likelihood)
nothing that we put into dynFrame threads is meant for in-combat execution anyways, so to avoid random unexpectedly short timeouts, pause execution if combat starts, and resume after combat ends. There's potential for WeakAuras to be 'broken' during that combat session (due to dynamic groups being Pause()'d), but we probably couldn't have unbroken it given that ResumeAllDynamicGroups is too costly to call during combat lockdown without risking a timeout. Fixes WeakAuras#4967 (or at least, reduces its likelihood)
Is there an existing issue for this?
Description
WA occasionally gets stuck on loading after using /wa. I'd say this didn't happen prior to 10.2.6
no idea if colorpicker plus can cause this
included a screenshot
WeakAuras Version
5.12.5
World of Warcraft Flavor
Retail (Default)
World of Warcraft Region
EU
Tested with only WeakAuras
Lua Error
Reproduction Steps
can't reproduce reliably
Last Good Version
No response
Screenshots
Export String
No response
WeakAuras.zip
The text was updated successfully, but these errors were encountered: