Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[BUG][code-analyzer] sfge: a null collection element passed to a typed parameter aborts the entry point (NOT_A_MATCH, re: #1195)

Offen
  • Stimmt etwas nicht?
#2,096 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
74/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
devtools

Rechercherichtung

Beginne mit MethodTypeMatchUtil.getMatchRank und LiteralExpressionVertex.Null und reproduziere das Problem anschließend mit dem bereitgestellten SFDX-Fixture und dem sf code-analyzer-Befehl. Vergleiche die Pfade matchesParameterType und rankParameterMatch und prüfe vorhandene Tests rund um diese Klassen. Erledigt ist die Aufgabe, wenn das Null-Element der Collection die Analyse nicht mehr abbricht und ein Regressionstest diesen Fall abdeckt, ohne Entry-Point-Funde zu verlieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

#1195 was closed on 2025-09-04 after the original reporter said it no longer reproduced. It still occurs on code-analyzer 5.15.0 / sfge 0.24.0, at the same throw site (TypeableUtil.java:211).

Root cause. MethodTypeMatchUtil.getMatchRank calls both halves of the match contract back to back on the same pair:

// MethodTypeMatchUtil.java:186-193
private static int getMatchRank(int rank, Typeable typeable, ParameterVertex methodParameter) {
    if (typeable == null || !typeable.matchesParameterType(methodParameter)) {
        return NOT_A_MATCH;                       // graceful: sentinel, no throw
    }

    rank += typeable.rankParameterMatch(methodParameter);   // throws on the same condition
    return rank;
}

Both defaults live on Typeable and consult the same getTypes() set, so they agree — until a subclass overrides one. Nine classes override matchesParameterType; none override rankParameterMatch. Three of those overrides are deliberately more permissive, and two are safe because they widen getTypes() to match:

Class Override says it matches Also widens getTypes()? Result
ApexIdValue:55 its type or String yes (:68 -> [Id, String, Object]) consistent
ApexStringValue:150 its type or Id yes (:164 -> [String, Id, Object]) consistent
LiteralExpressionVertex.Null:319 everything (return true;) no — inherits [NULL, Object] throws for every parameter type except Object

LiteralExpressionVertex.Null is the only class that widens one half without the other, which is exactly the observed message (parameterType = String, type = [NULL, Object]).

Output / Logs
UnexpectedException: Did not expect NOT_A_MATCH when ranking parameter match. parameterType = String, type = OrderedTreeSet{internalList=[NULL, Object]}
	at com.salesforce.graph.ops.TypeableUtil.rankParameterMatch(TypeableUtil.java:211)
	at com.salesforce.graph.vertex.Typeable.rankParameterMatch(Typeable.java:41)
	at com.salesforce.graph.ops.MethodTypeMatchUtil.getMatchRank(MethodTypeMatchUtil.java:191)
	at com.salesforce.graph.ops.MethodTypeMatchUtil.parameterTypesMatch(MethodTypeMatchUtil.java:136)
	at com.salesforce.graph.ops.MethodUtil.getInvoked(MethodUtil.java:358)
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/NullCollectionElementToTypedParam.cls with the class shown below, plus a standard NullCollectionElementToTypedParam.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 NullCollectionElementToTypedParam {
    private static String label(String value) {
        return value == null ? 'none' : value;
    }
    @AuraEnabled
    public static void run() {
        List<String> items = new List<String>{ null };
        insert new Account(Name = label(items[0]));
    }
}

Note: the collection element is essential. String v = null; label(v); does not crash, because MethodTypeMatchUtil.getDeclarationTypeWhenAvailable substitutes the local's declaration vertex (String), whose matchesParameterType is the well-behaved default. A collection element has no declaration vertex to substitute, so the null-literal typed vertex survives. Map<String, String> with a null value behaves identically.

Expected Behavior

Give LiteralExpressionVertex.Null a getTypes() consistent with its "matches everything" claim — the same pattern ApexIdValue and ApexStringValue already follow.

Alternatively, have rankParameterMatch return NOT_A_MATCH instead of throwing; both callers already branch on that sentinel (MethodTypeMatchUtil.java:155, MethodUtil.java:777). That is one line, but it changes overload resolution wherever a permissive override currently crashes, so it probably wants a test sweep rather than a blind merge.

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)

A null sitting in a collection is entirely routine Apex, and this matches #1195's title exactly — "when null-assigned variable is passed into method".

If a unit test is more convenient for regression purposes, the defect also isolates to two calls without going through path evaluation. Against a LiteralExpressionVertex.Null pulled from a built graph and SyntheticTypedVertex.get("String"), all three of these hold on code-analyzer-sfge-engine@dev:

assertThat(nullLiteral.getTypes().contains("String"), equalTo(false));        // hierarchy excludes it
assertThat(nullLiteral.matchesParameterType(stringParameter), equalTo(true)); // guard passes
assertThrows(UnexpectedException.class,
        () -> nullLiteral.rankParameterMatch(stringParameter));               // next line throws

Happy to supply the full test file.

Workaround

Avoid null entries in collections that flow into typed method parameters, or seed the collection with a non-null placeholder. Not realistic in general.

Urgency

Moderate

Vorherrschende Sprache
TypeScript
Sterne
240
Forks
52
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus forcedotcom/code-analyzer

Alle Issues in forcedotcom/code-analyzer

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.