Script transform calling script library function resulting in AttributeErrors

[Jeff_Krol]

Hello,

I ran into an issue where I used a script transform on a dock that calls a function from the script library. It worked in testing, but when I put it into production, I quickly started getting binding overlays and errors in the logs that said something along the lines of:

AttributeError: 'com.inductiveautomation.ignition.common.script.Imm' object has no attribute system.dataset.toDataset

Here is the function:

def dropDownFormatter(dataset, valueFirst):

   if dataset is None:
      return dataset

   columnCount = dataset.getColumnCount()

   if columnCount < 2:
      return dataset

   headers = ["value", "label"]
   data = []

   for row in range(dataset.getRowCount()):
      if valueFirst:
         data.append([
            dataset.getValueAt(row, 0),
            dataset.getValueAt(row, 1)
         ])
      else:
         data.append([
            dataset.getValueAt(row, 1),
            dataset.getValueAt(row, 0)
         ])

   return system.dataset.toDataSet(headers, data)

From IA support:

"The issue effects script transforms primarily because script transforms are compiled and executed on the fly, each time the binding fires. This means they hit the class-loading/injection process repeatedly and unpredictably, making them far more likely to catch the race condition window where system hasn't been fully resolved yet."

Based on what they tell me, this is a known bug.

They also indicated that having any import system calls in our codebase will cause these issues. What's interesting is there was no import system in the script transform library, but there are instances of it in some existing code.

It seems like script transform library calls are especially susceptible to this, so I just put my transform logic right in the script transform dialog window. I was trying to create a reusable script transform library but for now I'd rather the code just work consistently.

I've seen general advice on the forums to never use import system in scripting logic:

Ignition Edge sends emails but no attachments

Similar setup here - nothing against you personally, it's just that each time I work through a "person got a mountain of code from an LLM" post and try to guide them through all the things it did wrong makes me feel like Sisyphus. Top level notes: You should only rarely need to import anything in small Ignition scripts. Any imports you do use, you should be judicious about. You should never import system or anything from system. You should never use Jython's datetime library. You should (a…

Can anyone weigh in on the reason to not use import system in any scripts? Also, has anyone else had issues using a script library call from a script transform?

[paul-griffith]

[IGN-6503]Project Library Script Initialization Races

Are you annoyed by pseudo-random breakage in Ignition project library scripting? Odd top-level constants being garbled, or operations in the top level that have side effects running twice? Or more? Not happening much, but always around project edits, and sometimes even on gateway restart? Yeah, me too. Poking around under the hood back in the spring, for a module development task, I ran across some problematic IA bytecode and pinged some people. But it went nowhere, as I co…

Fixed in 8.3.

[Jeff_Krol]

Thank you for the quick response and the thread for reference. It sounds like the bug that's fixed in 8.3 is the issue with scripts loading properly and that should resolve using library scripts from script transforms. I'll recommend to my team that we write our functions directly in the script transform window until we can validate this in 8.3.

Are the following statements correct?

1. We should never call import system.
2. Any other imports that we need should be done at the top of a script library package.
3. The nature of how script transforms work exacerbates the issue with modules loading correctly.

Thanks for your help understanding this!

[paul-griffith]

1. Correct
2. Yes, that's the ideal case for best performance
3. Essentially correct.

[nminchin]

From a performance standpoint re importing modules within a function instead of in the module, I can tell you that recursively calling a function that converts Java objects into py objects for a moderately sized list can easily add 300ms or more of execution time. Ask me how I know 300ms might not seem like much, but any lag to an interface updating is frustrating