Have you tried to resolve this issue yourself first?
Bug Description
Engine: sfge (Salesforce Graph Engine) · Rule: ApexFlsViolation (DevPreview) · Selector: --rule-selector sfge
An array/index load whose target resolves to an indeterminate ApexSingleValue aborts path evaluation — in a method that already returns an indeterminate value for every other input.
List<String> parts = (List<String>) byKey.get('k'); // byKey is Map<String, Object>
String first = parts[0];
ApexMapValue.apply takes the indeterminate branch of METHOD_GET (ApexMapValue.java:183-191) and returns a bare indeterminate value typed from the map's declared value type. Because that type is Object, build() yields an ApexSingleValue rather than an ApexListValue, and indexing it hits the unhandled else at PathScopeVisitor.java:894. The Apex cast to List<String> does not help — the engine keeps the map's declared value type. JSONDeserializeFactory.java:78-79 builds the same shape for types it declines to model, so this is not the only route in.
The fix already exists in the same method:
// PathScopeVisitor.java:874-902
private ApexValue<?> getIndeterminantArrayLoadValue(@Nullable ApexValue<?> apexValue) {
final Typeable listType;
if (apexValue instanceof ApexListValue) { ...
} else if (apexValue instanceof ApexForLoopValue) { ...
} else if (apexValue instanceof ApexSoqlValue) { ...
} else if (apexValue == null) {
listType = null; // <-- null is fine
} else {
throw new UnexpectedException(apexValue); // <-- everything else aborts
}
ApexValueBuilder builder = ApexValueBuilder.get(this).withStatus(ValueStatus.INDETERMINANT);
if (listType != null) {
return builder.declarationVertex(listType).build();
} else {
return builder.buildUnknownType(); // <-- the null branch lands here
}
}
A null apexValue — strictly less information than an indeterminate ApexSingleValue — falls through to buildUnknownType().
Output / Logs
UnexpectedException: ApexValue(ApexSingleValue) {status=INDETERMINANT, declarationVertex=SyntheticTypedVertex@...,
valueVertex=null, returnedFrom=ApexValue(ApexMapValue) {status=INDETERMINANT,
declarationVertex=Parameter{... Type=Map<String,Object> ... Name=byKey}} ...}
at com.salesforce.graph.symbols.PathScopeVisitor.getIndeterminantArrayLoadValue(PathScopeVisitor.java:894)
at com.salesforce.graph.symbols.PathScopeVisitor.afterVisit(PathScopeVisitor.java:810)
at com.salesforce.graph.symbols.DefaultSymbolProviderVertexVisitor.afterVisit(DefaultSymbolProviderVertexVisitor.java:737)
at com.salesforce.graph.vertex.ArrayLoadExpressionVertex.afterVisit(ArrayLoadExpressionVertex.java:58)
Steps To Reproduce
- Create an empty SFDX project (
sfdx-project.json with a single force-app package directory).
- Add
force-app/main/default/classes/IndeterminateMapGetIndex.cls with the class shown below, plus a standard IndeterminateMapGetIndex.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 IndeterminateMapGetIndex {
@AuraEnabled
public static void run(Map<String, Object> byKey) {
List<String> parts = (List<String>) byKey.get('k');
String first = parts[0];
Account a = new Account();
a.Name = first;
insert a;
}
}
Expected Behavior
Routing the else to listType = null would make the unknown case behave like the already-unknown case, which is what the method's name and Javadoc promise ("Generates a single indeterminant value based on the type contained in apexValue").
The caller has the same gap: PathScopeVisitor.java:804-806 carries a matching bare throw new UnexpectedException(vertex) on its own else.
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)
Map<String, Object> is the standard way to accept a loosely typed payload in an @AuraEnabled method, and indexing a list pulled out of one is routine.
Costs three @AuraEnabled entry points in our codebase via two different routes — the map shape above, and a static initializer in a shared constants class that indexes a String.split() result. The second is the worse pattern: because it sits in a constants class, every entry point that touches it inherits the abort.
Workaround
Assign through an intermediate typed local that sfge can resolve, or avoid indexing values pulled out of an Object-valued map on paths that reach DML. Neither is dependable.
Urgency
Moderate
Have you tried to resolve this issue yourself first?
Bug Description
Engine:
sfge(Salesforce Graph Engine) · Rule:ApexFlsViolation(DevPreview) · Selector:--rule-selector sfgeAn array/index load whose target resolves to an indeterminate
ApexSingleValueaborts path evaluation — in a method that already returns an indeterminate value for every other input.ApexMapValue.applytakes the indeterminate branch ofMETHOD_GET(ApexMapValue.java:183-191) and returns a bare indeterminate value typed from the map's declared value type. Because that type isObject,build()yields anApexSingleValuerather than anApexListValue, and indexing it hits the unhandledelseatPathScopeVisitor.java:894. The Apex cast toList<String>does not help — the engine keeps the map's declared value type.JSONDeserializeFactory.java:78-79builds the same shape for types it declines to model, so this is not the only route in.The fix already exists in the same method:
A
nullapexValue— strictly less information than an indeterminateApexSingleValue— falls through tobuildUnknownType().Output / Logs
UnexpectedException: ApexValue(ApexSingleValue) {status=INDETERMINANT, declarationVertex=SyntheticTypedVertex@..., valueVertex=null, returnedFrom=ApexValue(ApexMapValue) {status=INDETERMINANT, declarationVertex=Parameter{... Type=Map<String,Object> ... Name=byKey}} ...} at com.salesforce.graph.symbols.PathScopeVisitor.getIndeterminantArrayLoadValue(PathScopeVisitor.java:894) at com.salesforce.graph.symbols.PathScopeVisitor.afterVisit(PathScopeVisitor.java:810) at com.salesforce.graph.symbols.DefaultSymbolProviderVertexVisitor.afterVisit(DefaultSymbolProviderVertexVisitor.java:737) at com.salesforce.graph.vertex.ArrayLoadExpressionVertex.afterVisit(ArrayLoadExpressionVertex.java:58)Steps To Reproduce
sfdx-project.jsonwith a singleforce-apppackage directory).force-app/main/default/classes/IndeterminateMapGetIndex.clswith the class shown below, plus a standardIndeterminateMapGetIndex.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
Routing the
elsetolistType = nullwould make the unknown case behave like the already-unknown case, which is what the method's name and Javadoc promise ("Generates a single indeterminant value based on the type contained inapexValue").The caller has the same gap:
PathScopeVisitor.java:804-806carries a matching barethrow new UnexpectedException(vertex)on its ownelse.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)
Map<String, Object>is the standard way to accept a loosely typed payload in an@AuraEnabledmethod, and indexing a list pulled out of one is routine.Costs three
@AuraEnabledentry points in our codebase via two different routes — the map shape above, and a static initializer in a shared constants class that indexes aString.split()result. The second is the worse pattern: because it sits in a constants class, every entry point that touches it inherits the abort.Workaround
Assign through an intermediate typed local that sfge can resolve, or avoid indexing values pulled out of an
Object-valued map on paths that reach DML. Neither is dependable.Urgency
Moderate