Have you tried to resolve this issue yourself first?
Bug Description
Engine: sfge (Salesforce Graph Engine) · Rule: ApexFlsViolation (DevPreview) · Selector: --rule-selector sfge
ApexListValue.apply asserts sort takes zero parameters:
// ApexListValue.java:305-308
} else if (METHOD_SORT.equalsIgnoreCase(methodName)) {
validateParameterSize(vertex, 0);
// Intentionally left blank
// TODO: Does this need to sort?
Apex added List.sort(Comparator<T>) in API 61 (Spring '24). The zero-argument assertion was never updated, so the overload throws at ApexValue.java:610.
List<Account> accs = new List<Account>();
accs.sort(new ByName());
Output / Logs
UnexpectedException: MethodCallExpressionVertex{fullMethodName=accs.sort, ... MethodName=sort}:
com.salesforce.graph.symbols.apex.ApexValue.validateParameterSize(ApexValue.java:610);
com.salesforce.graph.symbols.apex.ApexListValue.apply(ApexListValue.java:306);
com.salesforce.graph.symbols.PathScopeVisitor.handleApexValueMethod(PathScopeVisitor.java:1487); ...
Steps To Reproduce
- Create an empty SFDX project (
sfdx-project.json with a single force-app package directory).
- Add
force-app/main/default/classes/ListSortComparator.cls with the class shown below, plus a standard ListSortComparator.cls-meta.xml (apiVersion 62.0).
- Add
code-analyzer.yml:
engines:
sfge:
java_thread_timeout: 900000
java_thread_count: 4
- Run:
sf code-analyzer run --rule-selector sfge --workspace . --config-file code-analyzer.yml
- The run reports an
InternalExecutionError for the entry point instead of analysing it. That entry point yields no ApexFlsViolation findings at all, and nothing in the summary indicates coverage was lost.
public with sharing class ListSortComparator {
public class ByName implements Comparator<Account> {
public Integer compare(Account a, Account b) { return 0; }
}
@AuraEnabled
public static void run() {
List<Account> accs = new List<Account>();
accs.sort(new ByName());
insert accs;
}
}
Expected Behavior
sort(Comparator) should be accepted. Suggested fix: validateParameterSizes(vertex, 0, 1). The existing body is already a no-op with a // TODO: Does this need to sort?, so accepting the comparator argument costs nothing beyond the assertion change.
Operating System
macOS 26.5.2
Salesforce CLI Version
@salesforce/cli/2.147.7 darwin-arm64 node-v24.5.0
Code Analyzer Plugin (code-analyzer) Version
code-analyzer 5.15.0
Node Version
v24.5.0
Java Version
openjdk version "11.0.32" 2026-07-21
Python Version
N/A
Additional Context (Screenshots, Files, etc)
One signature / one entry point in our codebase, but Comparator is the modern idiom for sorting in Apex and adoption is only going to grow, so this will get more common rather than less.
Workaround
Fall back to implements Comparable on the element type and call the zero-argument sort(), which sfge accepts.
Urgency
Moderate
Have you tried to resolve this issue yourself first?
Bug Description
Engine:
sfge(Salesforce Graph Engine) · Rule:ApexFlsViolation(DevPreview) · Selector:--rule-selector sfgeApexListValue.applyassertssorttakes zero parameters:Apex added
List.sort(Comparator<T>)in API 61 (Spring '24). The zero-argument assertion was never updated, so the overload throws atApexValue.java:610.Output / Logs
UnexpectedException: MethodCallExpressionVertex{fullMethodName=accs.sort, ... MethodName=sort}: com.salesforce.graph.symbols.apex.ApexValue.validateParameterSize(ApexValue.java:610); com.salesforce.graph.symbols.apex.ApexListValue.apply(ApexListValue.java:306); com.salesforce.graph.symbols.PathScopeVisitor.handleApexValueMethod(PathScopeVisitor.java:1487); ...Steps To Reproduce
sfdx-project.jsonwith a singleforce-apppackage directory).force-app/main/default/classes/ListSortComparator.clswith the class shown below, plus a standardListSortComparator.cls-meta.xml(apiVersion 62.0).code-analyzer.yml:InternalExecutionErrorfor the entry point instead of analysing it. That entry point yields noApexFlsViolationfindings at all, and nothing in the summary indicates coverage was lost.Expected Behavior
sort(Comparator)should be accepted. Suggested fix:validateParameterSizes(vertex, 0, 1). The existing body is already a no-op with a// TODO: Does this need to sort?, so accepting the comparator argument costs nothing beyond the assertion change.Operating System
macOS 26.5.2
Salesforce CLI Version
@salesforce/cli/2.147.7 darwin-arm64 node-v24.5.0
Code Analyzer Plugin (code-analyzer) Version
code-analyzer 5.15.0
Node Version
v24.5.0
Java Version
openjdk version "11.0.32" 2026-07-21
Python Version
N/A
Additional Context (Screenshots, Files, etc)
One signature / one entry point in our codebase, but
Comparatoris the modern idiom for sorting in Apex and adoption is only going to grow, so this will get more common rather than less.Workaround
Fall back to
implements Comparableon the element type and call the zero-argumentsort(), which sfge accepts.Urgency
Moderate