"script ran too long" out-of-combat after 7.2.5
 

I've been getting a "script ran too long" error with several addons after 7.2.5 hit. Interestingly this happens out-of-combat which is strange because I thought that the addon execution time limit applied only in combat.

Here are pastes of the errors:

• Details: https://pastebin.com/HtC9KW0Q
• Details: https://pastebin.com/jKXNtHdj
• ArkInventory: https://pastebin.com/QAUEmNRA

If you look at the lines where this is happening in Details, you'll notice that they are expected long-running functions (collectgarbage, UpdateAddOnMemoryUsage) that are surrounded by a `not InCombatLockdown()` clause. The Details author clearly had the same idea as me, that addon execution time limit is only enforced in-combat and it should be safe to call these expensive functions outside of combat. I know ArkInventory has some coroutine-stuff that yields in combat when it would otherwise hit the script execution time limit, but does not do so outside of combat.

So does anyone know, what has changed in 7.2.5 that causes script execution time to sometimes be enforced out of combat? This doesn't seem to be a consistent thing since if I type in chat something like
/run local x=1 for i=1,5*10^8 do x=x+i end
it will happily run for 4 seconds without any errors (as long as I'm not in combat).

I'm curious about this too. I have a configuration panel created on demand that contains quite a few textures and frames and can sometimes cause a small stutter when loaded for the first time. In almost all cases where that happens, this error is not produced, but as of 7.2.5 I've seen it once or twice.

These configuration panels are not accessible in combat, so the "script ran too long" error is truly pointless in this case. It also breaks the execution path and displays incomplete panels when it happens.

I'm really wondering what the point is. Why break the code if it's executed out of combat and seemingly has more to do with the UI back end than how the code is written? The end user of an add-on probably prefers a small frame stutter over broken code and lua errors. Hopefully it's just a bug.

Seems like it's applied out of combat now too, which is bad news for load on demand addons.

GetContainerItemLink and GetContainerItemInfo have been causing these errors for me in an addon I use, SmartBuff, especially after hearthing/portaling (ie. PLAYER_ENTERING_WORLD) but also at random times I've attributed to OnUpdate overload.

Basically cycling through bags and slots in a loop I've "de-compressed" the timing of these calls with a C_Timer.After as well as after the event which to-date has "fixed" this particular problem.

Still could be an issue with InCombatLockdown() saying "yeah you are out of combat, kappa".

Yea, I've never trusted InCombatLockdown() by itself. There's actually other functions that can't be trusted, like IsInGroup() returning false while in a group. My addons that deal with combat restrictions combine that with a variable set by the REGEN events. Both the variable and the function return have to be false before I do things meant for out-of-combat.

Seems unlikely.

I had the error portaling from major city to major city after logging in.

Just logging in, moving/jumping around, and then doing the long-running thing (opening bags, opening WA options) can sometimes trigger it for me. No zoning, no combat. There may or may not have been combat log events, not 100% sure.

I've only used InCombatLockDown() for years and never had any issue. If you log into the game while you are in combat it will return false, but thats intended.

Why on earth would it be intended to return incorrect information when you log into the game and are in combat? Does it really return true in this case only after some other event is processed?

Because it's not indicating if you are in combat or not, it's showing if you can make changes on secure frames or not.

So the implication is if one logs into the game and is in combat, then one can make changes on secure frames. If this is actually true, then Blizzard has a hole in their system. I would think that the secure frames are really not editable at that point either, but have not tested this theory.

It's not a hole it's only for like 2 seconds.
It would be more retarded when you dc in a bossfight then not a single addon could build up their secure frames after you log back in.

Save your time, because your theory is wrong.
Combat and lockdown are two separate things and the lockdown always fires after you enter combat. You can even use an event handler to do secure stuff in response to entering combat, which is useful for when you have some behaviour that happens on secure frames but should only happen in or out of combat.

If your theory was true, any action bar addon, unit frame addon or anything else using secure templates would not work when you log in after a disconnect mid-combat.

It's not a loophole or a bug or anything. It's just for a moment (probably before loading screen is done) so that you may construct the UI before lockdowns are in place.

It also occurs for just a moment whenever entering combat to give the UI time to react to being in combat. Showing target frame, a hidden actionbar, [combat] macros, etc.

To add to this, the lockdown occurs sometime after the event PLAYER_REGEN_DISABLED has been dispatched to all frames.

Yes. PLAYER_REGEN_DISABLED is the event to look for to know when you are entering combat.

event fires
UI updates for combat
InCombatLockDown() returns true

FYI according to Infus in response to my ticket about this error with WeakAuras, this is a Blizzard error that will be fixed with 7.3.

https://www.wowace.com/projects/weakauras-2/issues/981