Ghosted Scripts & Bindings

Is there a possibility that old scripts/bindings can still be running after they’re overwritten by a commit?

Some spooky backstory:
This may sound strange, but I’ve had an SQL query binding on a component in a template that was locking database resources in MsSQL. I checked the active processes in the Activity Monitor, and found a single connection acting as a head blocker, holding up multiple other processes. So I checked the details of the process for the query contents, and ran a project-wide scan to locate its origin. The search results indicated that the instruction originated from a numeric text field binding inside of a template. However, when I checked the template binding I found that the contained query is different (fixed in other words).

Screenshot of the Activity Monitor:

Screenshot of the search results:

Screenshot of the binding window:

This is made even more strange by the fact that this project has been backed-up and restored to a new gateway since the change was made. The version of the Gateway is 7.9.4. A coworker of mine also claims that an old tag-change event script was littering our logs for weeks after he committed a change that removed it. Has anyone seen such trickery before, or could something else be happening that I don’t see?

Any help with this mystery would be greatly appreciated! :ghost:

Yes, I am seeing a similar situation with a tag event script via a UDT. The UDT has been used for a very long time, and is used on multiple servers (all 7.9.3), but only one server still calls the old version of the script, and it calls the new script… I use version loosely because the old script is nowhere to be found. I know it’s the old version because it has a print statement that is called frequently and was only intended to be used during the test stage, very bizarre. And yes, the wrapper.log is being littered, but I cannot find a way to remove this… maybe a new folder name or tag path.

If it is an event script that call no other script, it would be a bug for an old version to linger. But if there is any way for a long running background thread to have stored an object from that old script version, and call the script through the old object version, it is quite possible. Take a look at this comment and its thread.

1 Like

I deleted the UDT, restarted the gateway, and still see an error from the deleted UDT script being logged in the wrapper.log.

I searched the Ignition directory, and found a reference to the deleted UDT still showing in the config.idb. It would be nice for this UDT to be gone, so the wrapper.log stops filling up with bogus errors…