v8.1.28
When making changes to scripts that are called by Perspective component actions, if you don't edit a Perspective View as well before you save, the script changes aren't pushed to the session, and clicking on buttons that call these edited scripts will still run the old ones.
On a side note, this doesn't really make sense to me, since the scripts are run on the gateway, not the sessions... I'd really like to understand why this is the case
I would presume the sessions are holding onto the old ScriptManager. Sounds like a bug.
This is a bug that we've already fixed, but it's awaiting QA. Expect the fix in 8.1.30 or .31, probably.
I still have this issue in 8.1.48. It is annoying when developing, but I am more concerned that this might happen when "pushing code to prod" with 200 clients open and only half getting the updated script?
You should contact our support department officially (https://support.inductiveautomation.com/hc/en-us) so they can work with you to isolate the problem and we can get it fixed. We haven't had any other reports of the issue since around the time Nick reported it here.
@jacob_geers: Did you resolve the issue? We’ve been running into the same problem…
I created a support ticket #156038 with a video of the issue and some gateway backups but support could not reproduce the issue. Their idea was that threads were being blocked when attempting to push the changes over to the session from the gateway. Next step was to take thread dumps at 3sec intervals when the issue happens, but I haven’t spend time on it since.
@jacob_geers : Thanks for sharing!
@paul-griffith : I’m not sure if opening another ticket on my end with IGNITION Support would be of much help. Although no heap thread dumps have been provided by jacob_geers, I doubt I would be able to provide them in time either, as I don’t have direct access to the server where the Gateway is running. The process of obtaining the necessary permissions is quite strenuous—unless there’s a built-in function within the Designer that could be utilized for this purpose.
Given this, I hope you don’t mind me asking—do you have any new insight on whether this previous bug might still be unresolved?
The original bug Nick reported is fixed and I haven't heard any (other) reports of a regression besides you and Jacob. Contacting support is my recommendation because I'm just a developer who spends (too much) time on the forums - I'm not at all getting a representative sample, and maybe in support they're dealing with this every week. I doubt it, and I'd assume that if they are experiencing a lot of issues with this they'd have raised another internal bug ticket, but 
The point is data collection in the centralized location that deals with customer reported issues.
You can't really debug an issue with the gateway's internal state from the designer, because they're entirely separate processes.
The most likely explanation, to my mind, is a different bug, distinct from what Nick originally reported, that you and Jacob have managed to get into.
Do you happen to be using import statements in your Python code to bring in project library code? That's fundamentally flawed in 8.1 and all prior versions (fixed in 8.3, though still not recommended):
Note that cross-library import is not necessary to trigger this bug, but raises the likelihood of the race condition, and especially raises the chance of deadlock if you try the workaround in that topic.
Multiple gateway or client events racing at scripting startup is the primary cause, exacerbated if any initialization code is time consuming.
The fix in v8.3 covers both the initialization race and covers the work-around's deadlock risk. Don't use the work-around in v8.3.
The fix in v8.3 will have a performance impact on all uses of import that run in parallel with script init. Using import anywhere in Ignition other than the outer level of project library scripts is already disastrous for performance, but v8.3 puts an exclamation point on it.
(If you are using import anywhere in an event script or inside any def, you are screwing up.)
Thanks for the detailled response Pete and Paul!
Indeed, we’re working with importquite a lot. Since we aim to "outsource" code as much as possible for easier maintenance, using the import function seems like the best approach.
For example:
import time
import java.lang.Exception
from functions import ....
So, I don’t see any other way to continue with this approach other than by using import…
Just to clarify—if we were to upgrade to version 8.3, would this issue be resolved?
Use import as needed in the outermost level of code in your project library scripts, so the import occurs during initialization.
Do not use import pointing at other project library scripts. Simply use fully-qualified references (project library scripts are auto-imported).
Do not use import anywhere inside any function or class definitions, nor in any other event scripts.
Yes, upgrading to v8.3 will fix all of the initialization races and the corrupted objects and memory leaks that are associated. The above guide for import still applies, due to the performance hit of repeatedly taking the import lock.
Psssst! Don't ever import time. Don't use jython's stdlib for anything where Ignition provides appropriate functions, or java provides appropriate functions. time is one of the stdlib modules that should never be used in Ignition.