App Script Troubleshooting - Common Errors and Resolutions – TrackVia

This article details the most common App Script errors, their causes, and how to resolve them. Click on a link below to jump to that section:

Compilation Errors
Runtime Errors
No Error, but Script Does Not Work
Additional Troubleshooting Tips

Common Compilation Errors

Here’s a list of common compilation errors that you may run into, what they mean, and how you might be able to resolve them.

👀 NOTE: “X” is used anywhere that the error will change based on the specific script.

Error Message	Cause	🛠️ Fix
`Expecting X, found X @ line X, column X`	Anytime the script contains an open parenthesis, quote, or curly bracket, the script also needs to contain a closing quote `""`, parenthesis `()`, or curly bracket `{}`. This error will be produced when the script cannot find the closing quote, parenthesis, or curly bracket.	🛠️ Find where the script is missing the quote, parenthesis, or curly bracket and add it in. 👀 NOTE: You can double click any opening parenthesis or curly bracket to see where the closing parenthesis or curly bracket is. The error should give a general idea of where the issue lies (e.g. “line 23”).
`The current scope already contains a variable of the name "X"`	The script contains two variables with the same name.	🛠️ Change the name of one of the variables. This commonly occurs when using constants because constants are named after field names, and it’s possible to have two separate tables containing two or more fields with the same name. Example: a Phone Number field in a Companies table and a Phone Number field in a Contacts table.
`Unexpected token X @ line X, column X`	There’s a syntax error somewhere in the script.	🛠️ Find the syntax error and resolve it. Check Groovy Documentation for exact syntax and operators. Example: using the incorrect `&` rather than the correct `&&`. The error should give a general idea of where the issue lies (e.g. “line 23”).
`The variable [X] is undeclared @ line X, column X`	The script contains a variable that hasn’t been declared.	🛠️ Fix 1: Look at the error to see what the undefined variable is. Declare the variable. 🛠️ Fix 2: Check for case sensitivity. 👀 NOTE: Variables are case sensitive. Example: `phoneNumber` is not the same as `phonenumber`. 🛠️ Fix 3: Check variable scope. The scope of a variable, or where it can be used, is determined by where it’s defined. Example: if a variable is defined inside an `if()` function, it can only be referenced inside that `if()` function. To use the variable outside the `if()` function, it must be defined outside the `if()` function.
`Cannot find matching method com.xvia.service.appscript. UserScriptLoggingService #info(java.util.List). Please check if the declared type is correct and if the method exists.`	You are attempting to pass the incorrect data type into a function.	🛠️ Pass the correct data type into the function. Functions expect a particular type of data to be used. Example: the `add()` function expects to receive numeric type inputs. If you attempt to pass Strings into the `add()` function, you will receive this error. 👀 NOTE: An easy way to convert variables from one data type to another is by using functions like `.toString()` or `.toInteger()`
`Cannot assign value of type java.lang.X to variable of type java.lang.X @ line X, column X`	You are trying to set a variable equal to a value that doesn't match its data type.	🛠️ Look for any place you’re assigning a value to a variable. Make sure that value is the same data type as the variable by either changing the variable data type or by converting the data type of the value. 👀 NOTE: An easy way to convert variables from one data type to another is by using functions like `.toString()` or `.toInteger()`. The error should give a general idea of where the issue lies (e.g. “line 23”)

Common Runtime Errors

Here’s a list of common runtime errors that you may run into, what they mean, and how you might be able to resolve them.
👀 NOTE: “X” is used anywhere that the error will change based on the specific script.

Error Message	Cause	🛠️ Fix
`The app script was interrupted. The maximum cpu time of X nanoseconds was exceeded.`	The app script could not finish its operation within the time limit. By default, all app scripts need to finish within 2 seconds. Use the following resolutions to reduce the amount of time it takes for the app script to execute.	🛠️ Fix 1: Wrap operations in `if()` statements so they only run when necessary. Example: if the script is doing two different things, wrap an `if()` statement around each part with a condition that ensures its part is only running when necessary. 🛠️ Fix 2: Reduce repetitive actions, especially `loadRecord()`, `find()`, and `getchildren()` Example: if the script is getting records from a child table multiple times, just get the records one time at the beginning of the script. 🛠️ Fix 3: Move script calculations into triggered fields, then reference those triggered fields in your script rather than performing the calculation. 🛠️ Fix 4: Only use `.each{}` when you need to loop over EVERY object in the list. Example: when you want to update a field value on all child records. Break out of loops if you don’t need to look at every child record. 🛠️ Fix 5: If the script cannot be completed within 2 seconds, contact TrackVia Support to increase the timeout period. Be aware that the actions performed in one app script can cause additional app scripts to execute. In this scenario, each app script may need to have its timeout increased.
`Query did not return a unique result: X`	Cause 1: A `loadRecord()` function found more than one record. `loadRecord()` functions will produce this error if they find more than one record that meets the specified criteria. Cause 2: The app script is referencing a table that doesn’t have a unique name in the account. Example: There are multiple “Customers” tables and the script contains a function like this: `getChildren(“Customers”, “Company”)`	Cause 1 Fixes: 🛠️ Fix 1: De-dupe the table the `loadRecord()` function is searching in so it only finds one record. 🛠️ Fix 2: Make the search term in the `loadRecord()` function more specific so it only finds one record. 🛠️ Fix 3: Use `find()`. The `find()` function will return a list of all records that meet the specified search criteria. Once you have the list of records, you can loop through them to find the specific record you’re looking for. Cause 2 Fixes: 🛠️ Fix 1: Change one of the table names so they are unique. 🛠️ Fix 2: Supply the app name in the function to differentiate between apps. Since the app name cannot be specified as an input in the `addChild()` or `getChildren()` functions, `save()` and `find()` can be used instead.
`Cannot invoke method X on null object`	You are attempting to run a method on a variable that is `null`. Example: `listName.contains(“true”)` when the object `listName` is `null`.	🛠️ Fix 1: Wrap an `if()` function around the operation that checks to make sure the variable isn’t `null` before performing the operation. 🛠️ Fix 2: Make sure the variable isn't `null` before performing the operation.
`Cannot add a value for an unknown field X`	The script cannot find field X.	🛠️ Check to make sure field X exists. 🛠️ Check the spelling and case of field X to make sure the script matches the actual name of the field in the table.
`Unknown or missing property "null"`	The wrong constant is being used somewhere in the script.	🛠️ Check to make sure the constants that are being used in the script are the correct ones. Remember that Relationship constants should only be used in `addChild()` and `getChildren()` functions. Otherwise, use the Relationship field constant instead.
`An app script cannot call addchild() for a BEFORE_INSERT event`	You are attempting to use the `addChild()` function in a `BEFORE_INSERT` script. This is not allowed as the parent record needs to exist before the child record can get created.	🛠️ Change the script Event Type to `AFTER_INSERT`.
`Wrong datatype provided for input`	You are trying to add a value to a field that doesn't match the field type. Example: A String into a Relationship field.	🛠️ Convert variables to the correct data types before inserting them into a field. 👀 NOTE: An easy way to convert variables from one data type to another is by using functions like `.toString()` or `.toInteger()`. Here’s a list of fields and the variable types they accept: Single Line: Anything Paragraph: Anything Number: Numeric data types like Integer, Double, or bigDecimal Percentage: Numeric data types like Integer, Double, or bigDecimal Currency: Numeric data types like Integer, Double, or bigDecimal Drop Down List: String Checkboxes: List Date: Date Date and Time: Date Application User: Map User Group: Map Email: String Link: String Relationship: Map

No Errors, but Script Does Not Work

Sometimes you may find that you are able to save an App Script without receiving a compilation error, and you are able to save a record successfully without the script throwing an error, but you find that the script did not perform it's actions as expected.

There are various reasons why this might occur, but the 3 most common reasons are detailed below.

1. A condition in the app script isn’t being met.

🛠️ Suggested Fix: If the script is supposed to perform some action, and that action is not occurring, check to make sure the condition is being met.

This is probably the most common issue. In the example App Script below, a field called Deactivation Date should be filled out when the Status field is set to “Inactive.” Status is a drop down field with two options, “Active” and “Inactive.”

if(currentValues[“Status”] == “inactive”) {
currentValues[“Deactivation Date”] = currentValues[“Updated”]
}

Everything looks good here, and the App Script should definitely execute. However, when we deactivate a record by updating the Status, the Deactivation Date never gets set. It’s most likely because the condition below is not being met:

if(currentValues[“Status”] == “inactive”)

In this case, it’s due to case sensitivity. The script is checking for “inactive” with a lowercase “i” and it's not finding it so the condition will never be met and the Deactivation Date will never be set.

2. The App Script is set to the wrong Event Type.

Each App Script is tied to an Event Type that determines when the script should run. If a script is not running, check to make sure it’s set to the correct Event Type.

Example: if a script should run when a record is created, make sure the Event Type is BEFORE_INSERT or AFTER_INSERT. Or, if a script is referencing a triggered field, make sure the Event Type is AFTER_INSERT or AFTER_UPDATE.

For more information about App Script Event Types, refer to the Intro to App Scripts article.

3. The script is referencing a Calculated field.

While App Scripts can reference Triggered fields (in “After” Event Types), they CANNOT reference Calculated fields, Record IDs, or Auto Counters. Referencing any of these types of fields in your script won’t produce any results or error messages.

If you’ve checked the above common issues, and the script is still not completing the expected action, please see the additional troubleshooting tips listed below.

Additional Troubleshooting Tips

If you’re getting a generic error that’s not listed above and doesn’t give much context as to what the issue could be, then you’ll need to spend more time digging into the script. There are two extremely helpful troubleshooting tools you can use to identify the issue, Loggers and Commenting, which are outlined below.

Loggers

The most powerful tool in your troubleshooting toolbox is the logger. A logger is a way that we can output a value to the error log during script execution. It’s extremely useful because it allows us to see what values are being passed through the script and check to see what parts of the script are being executed.

In the example script below, a field called Deactivation Date should be filled out when the Status field is set to “Inactive.” Status is a drop down field with two options, “Active” and “Inactive.”

String status = currentValues[“Status”] as String
if(status == “inactive”) {
currentValues[“Deactivation Date”] = currentValues[“Updated”]
}

If the script saves, and we can save a record, but the action (setting the Deactivation Date to the Updated date) never completes, use loggers to check:
A. what “status” is, and
B. if the script is ever getting into the condition.

Here’s what that would look like:

String status = currentValues[“Status”] as String
logger.info(status)
if(status == “inactive”) {
logger.info(“Passed!”)
currentValues[“Deactivation Date”] = currentValues[“Updated”]
}

After attempting to trigger the script to run by saving a record, the first logger, logger.info(status), will output “Inactive” to the error log.

The second logger, logger.info(“Passed!”), will output the word “Passed!” to the error log ONLY IF the condition is met.

This should be enough to tell us that the variable “status” was set to “Inactive” which is obviously not equal to “inactive” and we never saw the word “Passed!” in the error log so the condition was never met. It’s clear that we just need to adjust our condition.

The function logger.info()can be used as many times in a script as needed to see what’s occurring as the script executes. However, we recommend removing loggers (or commenting them out) once the script is working as intended as they do take some processing time and can therefore slow down the performance of a script.

👀 NOTE: loggers can only output strings of text so we must pass a String into the function as we did in the example above.

Commenting

Comments are pieces of a script that do not get executed when the script runs. They are created by adding // before a string of text or by wrapping a string of text in /* and */.

While comments are normally used to describe the contents of a script for informational purposes, they can also be quite useful as a troubleshooting tool.

Sometimes, scripts can be long and complex. If a long and complex script isn’t working properly, it can be hard to identify the issue. Comments can be used to help with the process of elimination.

If our script was producing an error when we save a record, but we don’t know why, we can start commenting out pieces of the script until the script stops producing that error message. Once the error message stops showing up, it’s easy to identify the issue since it was likely caused by the last line(s) of code that we turned into a comment.

Related Articles: