Troubleshooting

From time to time, you experience an issue with Salesforce Code Analyzer. Read through these common issues and learn how to fix them.

Review these common scanner run issues.

It’s actually working as designed. Some rules are enabled by default by ESLint, while some other rules aren’t. Executing scanner run without filters causes only default-enabled rules to be invoked, and specifying a category filter with scanner run includes all rules under the selected categories to be invoked irrespective of their default-enabled setting. As of today, we don’t provide a way to modify default-enabled settings for rules.

Code Analyzer’s node process runs with a default limit of 2 GB of memory. This limit can be changed by configuring the max-old-space-size node option. The required memory depends on the files included in the --target parameter. This example increases the memory value to 4 GB for a single invocation of Code Analyzer.

Verify whether the affected Visualforce pages or components render correctly.

If your Visualforce pages or components include HTML tags that include PMD attributes, review PMD-Visualforce open issues. PMD can provide the fix for you.

If you invoke the eslint and eslint-lwc engines in the same run, and execute them on the same files, Code Analyzer returns duplicate violations.

You see this warning:

At least one file was processed by both ESLint and ESLint-LWC simultaneously, which could result in duplicate violations. Customize targetPatterns properties for eslint and eslint-lwc engines in ~/.sfdx-scanner/site.data.versions-v3.configfile to remove overlap on the following file(s):

To prevent duplication, use target patterns glob syntax and edit your config file.

• For eslint-lwc targetPatterns, replace "**/*.js" with the pattern of your LWC files
• For eslint targetPatterns, add the converse of your estlint-lwc files

For example, your LWC files are stored in a directory called lwc. Include this information in your config file.

Your path names likely contain characters that cause issues. We recommend that you don’t use these characters in path names.

Review these common scanner run and eslint-typescript issues.

The ESLint engine requires that any scanned TypeScript files must be included by the tsconfig. Read more in the typescript-eslint GitHub repo.

Update your tsconfig’s include attribute to include <file_name>.

The most likely cause is that you’re scanning TypeScript files without realizing it.

If you’re using a dependency management framework like Yarn, Bower, or npm, make sure that Code Analyzer ignores those folders because dependent modules can have TypeScript files that you don’t know about.

Make sure that the entries for ESLint and eslint-typescript in ${HOME}/.sfdx-scanner/Config.json exclude the folder used by your framework. For example, to exclude Yarn and npm dependencies, add !**/node_modules/** to the targetPatterns property, and add !**/bower_components/** to exclude Bower dependencies.

Review these common Salesforce Code Analyzer (Code Analyzer) scanner run issues.

• Make sure that you reference only PMD features and classes that are available in version 6.43.0.
• Check that you’re using correct syntax.
• Check that the compilation CLASSPATH contains the correct version of the PMD binary.

• Double-check that the rules in your XML are exclusively XPath-based. If any of the rules use custom Java, then a JAR is required.
• Ensure that the XML’s path includes category as a directory.

• Check that the XML rule definition file is included in the JAR. To list the files in your JAR, run jar tf /your/jar/file.JAR.
• Make sure that your XML file is in a PATH that includes category as a directory.
• Check that your class files are included in the JAR.
• Confirm that the PATH to the class files reflects the package structure in the Java file.

One possible reason is that the Java version you used to build your code is different from the version Code Analyzer uses to invoke PMD. Make sure that you compile your Java code with the same Java version and path that’s listed in the java-home key in <HOME_DIR>/.sfdx-scanner/Config.json.

One possible reason is that you referenced a class in your custom rule Java code from the PMD library that’s not available in the version of the PMD engine used by Code Analyzer. Check the release notes for the current version of the PMD engine used by Code Analyzer, and make sure that you reference only PMD features and classes that are available this version.

Review these common custom configuration issues.

In the directory where you execute the scanner run command, install the required ESLint dependencies using npm install <some_module>.

Review these issues common to multiple commands.

Version 6.x of PMD has a Known Issue that causes a Java OutOfMemoryError when scanning some Javascript files. Scanning Javascript with PMD was removed from the current version of Code Analyzer. We plan to restore this feature in a future version. To resolve this error, make these changes to the PMD engine node in your ${HOME}/.sfdx-scanner/Config.json file.

Remove the **/*.js element from PMD engine’s targetpatterns array.

Remove the javascript element from PMD engine’s supportedLanguages array.

Example:

Review these common PMD issues.

We removed the PMD support for all languages except:

• Apex
• Java
• Visualforce
• XML

Remove any languages besides the languages in PMD engine’s supportedLanguages array in your ${HOME}/.sfdx-scanner/Config.json file. To request that we add more languages, create an issue on our Github repo.

The specific error is Exception in thread "main" java.lang.OutOfMemoryError: Java heap space.

The solution is to increase your maximum Java heap space settings. One way is to add -Xmx<SIZE> to the JDK_JAVA_OPTIONS environment variable before running the scanner run command, where <SIZE> refers to the desired heap size. For example, to set it to 2GB:

Review these common Salesforce Graph Engine issues.

To resolve InternalExecution errors, follow these guidelines.

1. Read the error message that you received.
2. Does the error message mention a specific vertex with a DefiningType and BeginLine? These values correspond to an Apex class and line number. Examine what’s happening in that line of code, and re-read the error message. With the additional context, is there any debugging that you can do or refactoring that you can try to work around the issue?
3. Does the error message mention the name of a specific method, variable, or property in your code? Search your codebase for references to it. Then re-read the error message.
4. Delete your ~/.sfdx-scanner/sfge.log file, and then rerun the command. This action produces a clean log file containing just the logs from the most recent execution. Read those logs. Look for:
   • Exceptions and stack traces. The exception often provides more information such as DefiningTypes. If you log an issue, it’s important to include the stack trace.
   • TODO: PathScopeVisitor.getApexValue() can currently only support chains of length 2 or lower. keySequence=[X, Y, Z] This message indicates that your code has a reference chain of length 3 or greater. Graph Engine is unable to process these references and treats them as indeterminate values. It’s possible that fixing these references can fix your issue.
     For example, instead of this reference:
     String s = someObj.innerObj.someString;
     Try:
     InnerObj o = someObj.innerObj;
String s = o.someString;
5. Attempt to reproduce the issue in simpler code. The process of figuring out how to reproduce it gives you valuable insight into potential workarounds or fixes.
6. If you’re still blocked, log an issue and include:
   • a clean log
   • exceptions
   • stack traces
   • specific code that can be used to reproduce the issue
   • clear details about how to write the code.
   • if the error message indicated a specific vertex, include the line of code the vertex refers to.

Depending on the complexity of the source code, Graph Engine can take a long time to complete.

Use one of these methods to increase the timeout:

• Increase the SFCA_RULE_THREAD_TIMEOUT environment variable.
• Invoke the command with the rulethreadtimeout parameter.

Both methods take int values of the number of milliseconds to wait. The default timeout is 15 minutes.

To complete the execution within the timeout period, you can also reduce the number of files sent as --target, which reduces the number of entry points scanned per run.

This LimitReachedError is a current, known Graph Engine issue. Refer to our recommendations to reduce the probability of experiencing the heap space error.