Have you tried to resolve this issue yourself first?
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
- Create an empty SFDX project (
sfdx-project.json with a single force-app package directory).
- Add
force-app/main/default/classes/NewSObjectArgs.cls with the class shown below, plus a standard NewSObjectArgs.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 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
Have you tried to resolve this issue yourself first?
Bug Description
Engine:
sfge(Salesforce Graph Engine) · Rule:ApexFlsViolation(DevPreview) · Selector:--rule-selector sfgeSObjectType._applyMethodhardcodes a zero-parameter assertion fornewSObject:Apex has three overloads:
newSObject(),newSObject(Id), andnewSObject(Id recordTypeId, Boolean loadDefaults). Only the zero-argument form is accepted; the other two throw atApexValue.java:610.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
sfdx-project.jsonwith a singleforce-apppackage directory).force-app/main/default/classes/NewSObjectArgs.clswith the class shown below, plus a standardNewSObjectArgs.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
All three
newSObjectoverloads should be accepted. Suggested fix:validateParameterSizes(invocableExpression, 0, 1, 2)— that helper already exists immediately belowvalidateParameterSizeinApexValue.javaand 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
@AuraEnabledentry 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 assignRecordTypeIdas a field afterwards. Neither is possible when the SObject type is genuinely dynamic.Urgency
Moderate