Project scripts randomly inaccessible for short period

Ignition
1

We just had a strange occurrence on our 8.0.6 server, and I’m trying to figure out what happened and how to prevent it from happening again.

One of our projects has several scripts in the “Project Library” area. This project also happens to be our system-wide gateway scripting project. We have some gateway events in the same project which call into those scripts. About an hour ago, things started failing and the logs showed that the files in the project library were not being found.

For example, our list of project libraries looks like this:
designer_script_view

And suddenly, a timer based gateway event in that project started failing with: NameError: name 'signalfire_nodes' is not defined

Nothing about the project or server was changed around that time. I had just opened a Designer window, but was looking at an unrelated Perspective view in a different project.

For the next hour-ish all gateway events from that project which tried to reference the project library all failed with that name not defined error, for all the different libraries.

And then, just as suddenly, it started working again. I can’t see anything unusual in the wrapper.log near the beginning or end of this time range.

I tried searching around in the forum, but the closest I found are this thread and this thread. I checked, and we never import the project library files in any of our projects.

Is it okay to just refer to the functions in those library files like signalfire_nodes.some_function() or is there some more explicit naming we should be using to specify that an event should be looking in the current project or the global scripting project or some other place?

2

This has happened a couple more times since the other day. We are now making educated guesses on how to prevent it from happening again.

We do have a library file named “helpers” in more than one project, which we decided was probably unsafe, but aren’t sure why that would be messing up the “signalfire_nodes” library file, as that has only ever existed in one project.

As an attempt at fixing this, we went through our projects and moved all the project library files into a new “script package” folder with the same name as the project. We then had to search/replace every reference to those scripts and add the “projectname.” to the beginning. We did this change in the projects that were not the global scripting project, since they would have fewer references and the work could be done one at a time.

This seems to be preventing the issue so far.

I’m still curious if there is a better recommended method for naming or referencing script libraries to avoid this sort of issue.

3

Check memory utilization when something like this happens. I’ve noticed this kind of thing happens more frequently when I don’t have memory tuned correctly.

Also, if you have applied changes to a running client project, I’ve seen weird things happen, including not being able to find helper scripts, be they project level or global level scripts.

One of the recommendations that was given in one of my threads complaining about this issue was to not import any of your helper scripts, instead always use full reference to the methods.

4

If someone edits a project script and saves as they work, they could be saving with the script module in an non-working state–syntax errors, logical inconsistencies, et cetera. They may not even realize it if they only test when they think they are at an appropriate point.

Anyways, scripts that fail to execute all the way through every time they are saved (logged in the gateway as restarting project xxx scripts) will generate name errors for all callers until the problem is corrected.