[BUG][code-analyzer] sfge: JSON.deserialize with a Type variable throws ClassCastException and aborts the entry point

Start in JSONDeserializeFactory.java around lines 45-52 and inspect how the second JSON.deserialize parameter is converted to a ClassRefExpressionVertex. Use the supplied Type.forName reproduction to verify the dynamic argument no longer aborts analysis. Done means the entry point completes without an InternalExecutionError and treats the non-class-literal type as indeterminate.

Have you tried to resolve this issue yourself first?

• I confirm I have gone through the above steps and still have an issue to report.

Bug Description

Engine: sfge (Salesforce Graph Engine) · Rule: ApexFlsViolation (DevPreview) · Selector: --rule-selector sfge

JSONDeserializeFactory assumes the second argument to JSON.deserialize is always a class literal, and casts without checking:

// JSONDeserializeFactory.java:45-52
// This results in a CastExpression that wraps a MethodCallExpression. The
// second parameter is always
// a ClassRefExpressionVertex that denotes the Type
// (MyObject__c)JSON.deserialize(asJson, MyObject__c.class);

ApexValue.validateParameterSize(vertex, 2);
final ClassRefExpressionVertex classRefExpression =
        (ClassRefExpressionVertex) vertex.getParameters().get(1);

The comment says "always", but JSON.deserialize(String, System.Type) accepts any Type expression, and dynamic deserialization via Type.forName(...) is a normal pattern. When the argument is a variable, the cast fails.

Type targetType = Type.forName('Account');
Object o = JSON.deserialize(body, targetType);

Output / Logs

ClassCastException: class com.salesforce.graph.vertex.VariableExpressionVertex$Single cannot be cast to
class com.salesforce.graph.vertex.ClassRefExpressionVertex (...are in unnamed module of loader 'app'):
com.salesforce.graph.symbols.JSONDeserializeFactory.lambda$static$0(JSONDeserializeFactory.java:52);
com.salesforce.graph.ops.ApexStandardLibraryUtil.getStandardType(ApexStandardLibraryUtil.java:155);
com.salesforce.graph.symbols.PathScopeVisitor.afterVisit(PathScopeVisitor.java:1244); ...

Steps To Reproduce

1. Create an empty SFDX project (sfdx-project.json with a single force-app package directory).
2. Add force-app/main/default/classes/JsonDeserializeVarType.cls with the class shown below, plus a standard JsonDeserializeVarType.cls-meta.xml (apiVersion 62.0).
3. Add code-analyzer.yml:

   engines:
     sfge:
       java_thread_timeout: 900000
       java_thread_count: 4
   

4. Run:

   sf code-analyzer run --rule-selector sfge --workspace . --config-file code-analyzer.yml
   

5. 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 JsonDeserializeVarType {
    @AuraEnabled
    public static void run(String body) {
        Type targetType = Type.forName('Account');
        Object o = JSON.deserialize(body, targetType);
        Account a = (Account) o;
        insert a;
    }
}

Expected Behavior

When the type argument is not a ClassRefExpressionVertex, return an indeterminate value rather than throwing. The type genuinely is not statically known, which is a normal analysis outcome, not an engine error. An instanceof guard before the cast is sufficient.

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)

Worth prioritising beyond its frequency (1 signature / 1 entry point for us): JSON.deserialize into a runtime-chosen type is precisely the shape a taint-tracking engine most wants to reason about, and today it is the shape that reliably kills the analysis instead.

Workaround

Use a class literal where the type is statically known (JSON.deserialize(body, Account.class)). No workaround exists when the target type is genuinely dynamic.

Urgency

Moderate