Troubleshooting “Insufficient stack to continue executing the program safely”

13 min

Error

An Activate script fails with the following exception:

Exception: Insufficient stack to continue executing the program safely. This can happen from having too many functions on the call stack or function on the stack using too much stack space.

What this means

Activate detected that a script was close to exhausting the available call stack and stopped it safely.

This protection prevents uncontrolled script recursion from causing a StackOverflowException, which could terminate the process running the script, such as the Activate Orchestrator.

The protection is working as intended. Restarting the service or resubmitting the job may clear the immediate failure, but it will not correct the script that caused it.

Most likely cause

The usual cause is a script method that repeatedly calls itself without reaching a valid exit condition.

Recursion may be:

Direct: a method calls itself.

Indirect: method A calls method B, which calls method A.

Data-dependent: recursion stops for most inputs but not for a particular record.

Hook-driven: a hook calls an operation that triggers the same hook again.

Cross-script: scripts invoked through Evaluator.Invoke, included helpers, or another Activate operation form a call cycle.

Excessively deep: the recursion is valid, but the input creates more nested calls than the stack can safely support.

A function using unusually large amounts of stack space can also produce the error, although this is less common in Activate scripts.

Example of direct recursion

The following method has no terminating condition:

public object ProcessItem(string item) { return ProcessItem(item); }

Every call adds another method to the call stack. Activate eventually stops the script and reports the insufficient-stack exception.

How to troubleshoot the error

1. Identify the failing script

Use the failed job details and exception stack trace to identify:

The job and workflow step that failed.

The script parameter or web-form ServerScript being executed.

The last script method shown in the stack trace.

Any hook, shared helper, //@include, or imported script involved.

The input object or arguments being processed when the error occurred.

Repeated method names in the stack trace are a strong indication of recursion.

2. Trace the complete call path

Starting from the failing method, follow every method and Activate operation it calls.

Look for cycles such as:

ProcessUser -> UpdateUser -> RunUpdateHook -> ProcessUser

The cycle may cross script boundaries, so inspect calls made through:

Evaluator.Invoke(...)

Evaluator.InvokeOptional(...)

Job.ExecuteScript(...)

Included or imported script helpers

Child jobs or workflows

Connector and request hooks

Operations that can trigger the same event again

3. Check the exit condition

For each recursive method, confirm that:

A clear terminating condition exists.

Every recursive call makes measurable progress toward that condition.

The terminating value can actually be reached.

Null, empty, cyclic, or unexpected input cannot bypass the condition.

The recursion depth has a sensible maximum.

For hierarchical data, also check for cycles. A parent-child relationship such as A -> B -> C -> A will recurse indefinitely unless previously visited objects are tracked.

4. Check hook re-entry

A hook can cause indirect recursion when it performs the same operation that originally triggered the hook.

For example:

Update operation -> OnUpdate hook -> Performs another update -> OnUpdate hook -> Performs another update

Where possible, change the hook so it modifies the current request rather than starting the same operation again.

If re-entry is necessary, add an explicit guard using a job argument or other request-scoped marker:

public object RunHook() { var guard = Job.Arguments["HookAlreadyRunning"]; if (guard != null && guard.ToString() == "true") { return null; } Job.Arguments["HookAlreadyRunning"] = "true"; try { RunProtectedOperation(); } finally { Job.Arguments["HookAlreadyRunning"] = "false"; } return null; }

Use a guard that is scoped to the current job or operation. Avoid a global or static flag because concurrent jobs could interfere with one another.

5. Replace recursion where practical

For lists, trees, and parent-child structures, prefer an explicit loop, queue, or stack. This avoids consuming one program stack frame for every item.

When traversing data that may contain cycles, track visited identifiers:

public object ProcessHierarchy(Item root) { var pending = new Stack<Item>(); var visited = new HashSet<string>(); pending.Push(root); while (pending.Count > 0) { var item = pending.Pop(); if (!visited.Add(item.Id)) { continue; } ProcessItem(item); foreach (var child in item.Children) { pending.Push(child); } } return null; }

6. Test with the input that caused the failure

After correcting the script:

Test it with the original failing input.

Test empty and null inputs.

Test cyclic or self-referencing data where applicable.

Test an unusually deep hierarchy.

Confirm the job completes without repeatedly invoking the same hook or method.

What not to do

Do not:

Disable or attempt to bypass the stack protection.

Catch the exception and retry the same operation.

Increase recursion limits without first finding the call cycle.

Repeatedly resubmit the failed job without changing the script or data.

Assume a service restart has resolved the underlying problem.

Catching and ignoring the exception can leave the job partially processed and does not make further script execution safe.

When to contact Activate Support

Contact Activate Support if:

The stack trace contains only Activate product methods and does not identify a customer-authored script.

The problem occurs after an upgrade with no relevant script changes.

The script has a bounded call depth but still fails with shallow input.

You cannot identify which hook or script is re-entering.

The failure occurs in a standard, unmodified Activate package script.

Include the following information:

Activate version and build number.

Failed job ID.

Full exception and stack trace.

Name and path of the affected script parameter.

The workflow step or hook being executed.

Relevant job arguments, with credentials and sensitive data removed.

Whether the script is standard, customised, imported, or included by another script.

The smallest input that reproduces the problem.