Skip to content

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

Description

@willbutler

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions