[BUG][code-analyzer] sfge: SObjectType.newSObject(Id) and newSObject(Id, Boolean) abort the entry point

Read SObjectType.java around _applyMethod and ApexValue.java around validateParameterSize and validateParameterSizes. Run the sfge reproduction with the supplied code-analyzer.yml and verify that all three newSObject overloads are accepted, the entry point no longer aborts, and analysis can produce findings.

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

SObjectType._applyMethod hardcodes a zero-parameter assertion for newSObject:

// SObjectType.java:128-131
} else if (METHOD_NEW_S_OBJECT.equalsIgnoreCase(methodName)) {
    validateParameterSize(invocableExpression, 0);

Apex has three overloads: newSObject(), newSObject(Id), and newSObject(Id recordTypeId, Boolean loadDefaults). Only the zero-argument form is accepted; the other two throw at ApexValue.java:610.

Schema.SObjectType t = Account.SObjectType;
SObject s = t.newSObject(recordTypeId, true);

Output / Logs

UnexpectedException: MethodCallExpressionVertex{fullMethodName=t.newSObject, ... MethodName=newSObject}:
com.salesforce.graph.symbols.apex.ApexValue.validateParameterSize(ApexValue.java:610);
com.salesforce.graph.symbols.apex.schema.SObjectType._applyMethod(SObjectType.java:131);
com.salesforce.graph.symbols.apex.schema.SObjectType.executeMethod(SObjectType.java:121); ...

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/NewSObjectArgs.cls with the class shown below, plus a standard NewSObjectArgs.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 NewSObjectArgs {
    @AuraEnabled
    public static void run(Id recordTypeId) {
        Schema.SObjectType t = Account.SObjectType;
        SObject s = t.newSObject(recordTypeId, true);
        insert s;
    }
}

Expected Behavior

All three newSObject overloads should be accepted. Suggested fix: validateParameterSizes(invocableExpression, 0, 1, 2) — that helper already exists immediately below validateParameterSize in ApexValue.java and is documented for exactly this case ("Used when a method has overloads with different numbers of arguments").

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)

In our codebase: 8 occurrences across 4 distinct @AuraEnabled entry points.

Previously reported as #1175 (objType.newSobject((Id) recordId), the 1-argument overload), closed NOT_PLANNED as a duplicate in 2024. Still reproduces on 5.15.0.

Workaround

Use new Account() where the concrete type is known, or drop the record-type argument and assign RecordTypeId as a field afterwards. Neither is possible when the SObject type is genuinely dynamic.

Urgency

Moderate