Overview
Troubleshooting errors that come up while working with app scripts can be tricky business! This article outlines the most common app script errors, why they might appear, and explains how they might be resolved. If you run into an error that's not in this list, please let us know by reaching out to support@trackvia.com.
- Types of Errors
- Compilation Errors
- Runtime Errors
- No Error (but the script doesn't work)
- Additional Troubleshooting Tips
- Loggers
- Commenting
Types of Errors
App script errors can be grouped into two categories, compilation errors and runtime errors. Compilation errors, which display when you attempt to save a script, are produced when the script itself has some sort of issue, like a missing parenthesis. The app script cannot be saved until the issue is resolved. Below is an example of what a compilation error looks like:
Runtime errors, which display when a script is triggered to run, are produced when the script cannot complete the action it is attempting to complete. For instance, if the script is trying to add a number into a date field. The record cannot be saved until the issue is resolved. Below is an example of what a runtime error looks like:
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. “X” is used anywhere that the error will change based on the specific script.
|
Error: Expecting X, found X @ line X, column X Reason: 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. Resolution: Find where the script is missing the quote, parenthesis, or curly bracket and add it in. 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, eg. “line 23.” |
|
Error: The current scope already contains a variable of the name "X" Reason: The script contains two variables with the same name. Resolution: 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. Eg. a Phone Number field in a Companies table and a Phone Number field in a Contacts table. |
|
Error: Unexpected token X @ line X, column X Reason: There’s a syntax error somewhere in the script. Resolution: Find the syntax error and resolve it. Check Groovy Documentation for exact syntax and operators. Eg. using the incorrect “&” rather than the correct “&&”. The error should give a general idea of where the issue lies, eg. “line 23.” |
|
Error: The variable [X] is undeclared @ line X, column X Reason: The script contains a variable that hasn’t been declared. Resolution 1: Look at the error to see what the undefined variable is. Declare the variable. Resolution 2: Check for case sensitivity. Variables are case sensitive. Eg. “phoneNumber” is not the same as “phonenumber”. Resolution 3: Check variable scope. The scope of a variable, or where it can be used, is determined by where it’s defined. Eg. 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. |
|
Error: 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. Reason: You are attempting to pass the incorrect data type into a function. Resolution: Pass the correct data type into the function. Functions expect a particular type of data to be used. Eg. the add() function expects to receive numeric type inputs. If you attempt to pass strings into the add function, you will receive this error. An easy way to convert variables from one data type to another is by using functions like .toString() or .toInteger(). |
|
Error: Cannot assign value of type java.lang.X to variable of type java.lang.X @ line X, column X Reason: You are trying to set a variable equal to a value that doesn't match its data type. Resolution: 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. 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, eg. “line 23.” |
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. “X” is used anywhere that the error will change based on the specific script.
|
Error: The app script was interrupted. The maximum cpu time of X nanoseconds was exceeded. Reason: 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. Resolution 1: Wrap operations in if() statements so they only run when necessary. Eg. 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. Resolution 2: Reduce repetitive actions, especially loadRecord(), find(), and getchildren(). Eg. if the script is getting records from a child table multiple times, just get the records one time at the beginning of the script. Resolution 3: Move script calculations into triggered fields, then reference those triggered fields in your script rather than performing the calculation. Resolution 4: Only use .each{} when you need to loop over EVERY object in the list. Eg. 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. Resolution 5: If the script cannot be completed within 2 seconds, contact TrackVia Support to increase the timeout. 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. |
|
Error: Query did not return a unique result: X Reason 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.
Reason 2: The app script is referencing a table that doesn’t have a unique name in the account. Eg. There are multiple “Customers” tables and the script contains a function like this: getChildren(“Customers”, “Company”).
|
|
Error: Cannot invoke method X on null object Reason: You are attempting to run a method on a variable that is null. Eg. “listName.contains(“true”)“ when the object listName is null. Resolution 1: Wrap an if() function around the operation that checks to make sure the variable isn’t null before performing the operation. Resolution 2: Make sure the variable isn't null before performing the operation. |
|
Error: Cannot add a value for an unknown field X Reason: The script cannot find field X. Resolution: 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. |
|
Error: Unknown or missing property "null" Reason: The wrong constant is being used somewhere in the script. Resolution: 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 field constant not the relationship constant. |
|
Error: Wrong datatype provided for input Reason: You are trying to add a value to a field that doesn't match the field type. Eg. A String into a relationship field. Resolution: Convert variables to the correct data types before inserting them into a field. 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 |
|
Error: An app script cannot call addchild() for a BEFORE_INSERT event Reason: 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. Resolution: Change the script event type to after insert. |
What if the app script saves, and there’s no error when I save a record, but nothing actually happens?
There are many reasons why this might occur, but here are the 3 most common:
A condition in the app script isn’t being met: This is probably the most common issue. Let’s look at an example. In the below app script, 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 of if(currentValues[“Status”] == “inactive”) is not being met.
In this case, it’s due to case sensitivity. Our app 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.
If the app script is supposed to perform some action, and that action is not occurring, check to make sure the condition is being met.
The app script is set to the wrong event type: Each app script is tied to an event type that determines when the app script should run. If an app script is not running, check to make sure it’s set to the correct event type. For example, if an app script should run when a record is created, make sure the event type is “Before Insert” or “After Insert.” Or, if an app script is referencing a triggered field, make sure the event type is “After Insert” or “After Update.”
Please see our app script documentation for more information on event types.
The app script is referencing a calc 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 app 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 and we’ve outlined those 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.
Let’s look at an example. In the below app script, 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, then we’ll want to 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 we attempt to trigger the app 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 an app script. It’s also worth noting that 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 an app script that do not get executed when the app 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, app 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.
Comments
0 comments
Please sign in to leave a comment.