Errors during Execution

During execution, errors might be generated from various places. Common errors and how to deal with them is documented here.

Execution Errors

Cannot find module 'x' (Node action)

Happens when a Node.js action contains a requirement for a module which has not been installed. Fix:

• install the module with "npm install x" or via the "Plugins" → "Bridges" → "Node Bridge" menu.
• check your node-module-path ("Module Path" field in "Extras" → "Settings" → "Execution" → "External Script Interpreters") or the shell environment variable named "NODE_PATH".
• check if the modules was actually installed in the folder given by the module-path (noticing that there are both a global "node_modules" and a per-user "node_modules" folder)

Notice: a change of the module-path, does not affect already running node.js bridge connections. You have to close all current (node.js) connections and retry the action.  

ENOENT spawn git (npm install)

You should install git from [ https://git-scm.com/download/win ] first. Then try again.

No value for input "x" of step "Y"

A step's input pin has no input data. This happens if a step was started and a required input pin is missing. Notice, that this error is triggered only when a step-activity was triggered due to either the autostart flag (of the step) or by a trigger input value, or if the pin is non-triggering and another pin caused the trigger. And when the step's action accesses the input pin's data value.

In an elementary action, you can check for a pin to have received a value via the "pin.hasValue()" query.

Fix:

• provide an input value either by:
  • set a default value for the pin in the step's action-block definition (the schema)
  • give the step's pin a freeze value (constant or variable)
  • connect the step's input pin to another step's output pin or one of the compound action's inputs
• change the pin type to "parameter-pin" (especially if the step is in a loop). The pin will then no longer be considered in the trigger condition check, and the step will execute even if there is no value. However, a check for the presence of a value might be required inside the action to avoid an error there.

 

Output value x (x-class) is not compatible with datatype of pin "y" (y-class)

An invalid datum (not matching the pin's type) was written to an output pin, typically inside an action with elementary code.

Fix:

• check if the correct value is written to the pin
• change the output pin's datatype to match the value's
• change the output pin's datatype to Any (see note below)
• change the output pin's datatype to # (template type; see below)
• disable typechecks (usually not a good idea)

Note: Output pins with Any-type are problematic: if that pin is ever to be connected to a pin with a more specific type, the editor may complain and refuse to connect the pins (unless you force a connection by pressing the CTRL-key). A better solution is to declare the output's type as a unique template type (say "#1", "#2",... , where "#N" is chosen to be unique among the other pin's types of the action block in question. The pin will then adopt the type to whatever it is connected later (i.e. it behaves like an Any until connected, and will then take the type of whatever it is connected to).

Telegram-data for non-triggering pin "x" of inactive step "Y"

A telegram input pin (also called "mailbox pin") received a value after the step has already finished its execution. This is reported for non-triggering pins only - if it was triggering, a new activity would have been started. However, as the pin is non-triggering, the value is lost and there is noone to handle it.

Fix:

• check if a mailbox pin is really required
• either make sure that the mailbox input pin receives its value earlier (i.e. while the step is still being executed), or the target step is stopped later,
• or set the "ignore exception" behavior of the target step (see note below)

Notice: this error represents a special situation, in that actually neither the sending step, nor the mailbox-target step are individually responsible for the error. Also, because both have already finished, the error cannot be presented at either step's exceptionOutput pin, as this would lead to the strange situation, that both their trigger-output and their exception output pin's would be firing. Which would be illegal behavior. Therefore, the error is reported to the containing compound action, as its network is probably wrong.

In principle, this argument would also apply to the "ignore exceptions" flag. However, users found it convenient, to be able to ignore this error on the step level, instead of the compound level. Therefore a slight different semantic is implemented for this very error, in that it is ignored iff the target mailbox pin's step has the ignoreException flag set. Any errors internal in the target step are still reported via its exception output pin, if present.  

Trying to modify readonly variable: "x"

The variable "x" has the read-only attribute.

Fix:

• change the variable's "R/W" (read-write) attribute

Strange Behavior in Loops

See also "Common Errors".

Step in a Loop is not Executed or Executed only Once

This is a common problem with input pins which consume their value; be reminded that pin-connections are actually little event queues, and data values are transported as packets along them. Whenever such a packet arrives at a pin, it is enqueued and consumed, when the step is executed. At the same time, the arrival of such a packet is a trigger condition for the execution, unless the pin was declared as being non-triggering.

If a step is arranged in a loop (either explicitly, using enableIn-enableOut control pin loops, or via a repeat-count input or implicitly, by being fed with data from a multiple data generating step), pins may happen to have no input data available when triggered the second time.

This situation is especially common, when one pin is fed via a generator, and another pin's value comes from either a compound input pin, or another step which is executed only once.

Fix:

• change all input pins of the step which do not receive multiple values, and which should reuse the previous value throughout the loop to be "non-consuming" or "parameter" pins. This is done via the step's popup menu. Be aware that parameter pins are neither consuming, nor triggering. Thus, with a parameter pin, the step could in theory be triggered before a value arrives. You can also make it non-consuming, but still triggering, so the step will await for the first value to arrive at the pin (and, because it is non-consuming, it will remember this value for the next iteration of the loop). However, do not use this pin setup (trigger and non-consuming) for steps which are not in a loop; i.e. which are not triggered via an enable-input or other consuming triggering input. Because these might then behave like "machine guns" and re-trigger themself automatically.

Step in Loop is not Executed at All

If a step has an enableIn control pin, it will need a trigger value at this pin.
If you have instructed a loop which is connected via enableOut-enableIn control pins, the loop will not start, as no initial trigger ever appears.

To provide this initial trigger, add any dummy step, which generates an output and feed that as additional input to the loop-top's enableIn pin. Any output and especially a trigger-output will do.

The standard library provides such a block named "Start", which is actually a No-Operation block, and its sole purpose is to provide such an initial trigger condition. Make sure that the Start step is itself triggered, usually by setting its autostart execution flag.

Self Retrigger does not Work

A self trigger setup is done by connecting a step's output (either a data output or a trigger output) back to its own trigger input.

The idea is to fire the step again, once finished. A typical situation where this is useful is with the "[ Wait for Variable to Change ]" action, which is often used in GUI-action (and there usually waiting for some user interaction).

Be reminded, that there are two kinds of output pin behavior: buffered and unbuffered. Buffered means, that the value is written AFTER the step has finished successful, whereas unbuffered outputs are written immediately. If you have an unbuffered output connected to the steps own trigger input, the trigger will not be effective (because the step is already running, and the trigger is ignored then).

Therefore, connecting an unbuffered data output to the step's own trigger input will not work as expected. You should either make the output pin buffered, or use the steps trigger-output pin (which is by definition only sending out a value after the step has finished).

Action does not Finish in a Producer-Consumer Setup

A common pattern is that one step generates multiple data values (or tuples), and another one collects those, usually after being processed by some other action(s). For example, a test-data generator might produce data-tuples which are fed to a test case, and the results are collected to be further processed and generated as a summary output of the compound action. The problem here is that the collecting block needs to remain active until the last input value arrives, but it usually does not know, when to stop. There are multiple possible solutions to this:

• provide an END-token via a second pin and use that as a cancel or end-trigger. Many of the enumerating action blocks in the standard library provide such an END token already.
• use one of the "All Data Processed" or "No other Action active" blocks from the standard library. These can trigger a signal, if all data has been processed within a diagram and their output be used to signal the end condition.

---

Copyright © 2014-2024 eXept Software AG