[BUG] Page config "pages" dictionary emptied. Page Configuration lost

I ran into a bug on a project where the page configuration file
(\Inductive Automation\Ignition\data\projects\myProject\com.inductiveautomation.perspective\page-config\config.json)
reverted to no pages configured. I am not sure what happened or when it happened because auditing had not been set up. Since I don’t know exactly when it happened, the wrapper logs are not enough to tell what caused the problem.

Reaching out to Support, the person thought that perhaps the project that it inherits from overwrote the page config file. Since I didn’t have more detail, this was the furthest I got. I have since then configured auditing so that I can see when projects are saved and when resources are modified. This could help if this happens again, but I would like to come up with something to hopefully minimize the time spent fixing this issue if it happens again.

In an attempt to track this bug down, I wrote a file watcher script that looks at the config files in all of my projects and notifies me if a projects number of pages configured suddenly becomes zero. I have tested it in the script console, but I want this to run on Gateway Startup. I don’t think using a Gateway Update Script is the right way to go, as I’m not even sure if it is a save/update that is triggering this bug. I’m not sure how to use a timed script, since I want to continuously compare the file with its pervious version. This leads me to believe the gateway startup script is the best place for this to live.

I am worried about running a script indefinitely on the gateway, and I don’t know how to keep track of the thread and make sure there aren’t multiple of this script running at the same time, or making sure the thread is shut down on a gateway shut down script. The last thing I want is to run a script forever without an easy means of tracking it down and terminating it.

I am very new to Ignition, so I don’t know if this is the best way to solve this problem. Any insight into this problem would be greatly appreciated.

1 Like

Ah yes, I peeked over the support rep’s shoulder on this ticket. It seemed like an interesting one, I hadn’t seen it before.

Without knowing the nature of your script, it is hard to determine what the preferred gateway event to use is. However, if you want to continuously compare the file with it’s previous version, I feel like a timer script is probably the way to go.

Does the script take a long time to run? You can look at the currently running scripts under the Status > Diagnostics > Running Scripts page on your gateway webpage. You really don’t have to worry about the script having multiple instances running at the same time unless the execution time shown in the Running Scripts page is higher than the frequency at which your script is executed.

If its a timer script then I agree I wouldn’t need to worry about the execution time. But my initial draft of my config checker was just a “while True” loop that would watch for the config file to change. I would be wary running too many of these if I didn’t understand exactly when and where it was getting executed. I think I’ve decided to change to a timer script and rewrite the script a bit, then just store the data in tags so that the timer script can be paused if necessary and the information is retained for the most part. Hopefully I manage to catch this bug if it happens again.

Don’t do that. That ties up a event thread just like any kind of sleep. (Don’t do that either.)

Tying up a thread from a thread pool starves that thread pool. If you absolutely must run a persistent thread, launch it asynchronously. Look for all the topics here that discuss the pitfalls of persistent threads and objects.