Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,096 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
devtools

Direzione di ricerca

Inizia da MethodTypeMatchUtil.getMatchRank e LiteralExpressionVertex.Null, quindi riproduci il problema con il fixture SFDX fornito e il comando sf code-analyzer. Confronta i percorsi matchesParameterType e rankParameterMatch ed esamina i test esistenti relativi a queste classi. Il lavoro è completato quando l’elemento null della collection non interrompe più l’analisi e un test di regressione copre il caso senza perdere i risultati degli entry point.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
TypeScript
Stelle
240
Fork
52
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di forcedotcom/code-analyzer

Tutte le issue di forcedotcom/code-analyzer

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.