Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

sfge: path evaluation never converges on a ~40-field DTO mapper, silently abandoning every entry point that reaches it

Aberta
  • Algo errado?
#2,083 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
java, typescript
Domínio
security, tooling

Direção de pesquisa

Reproduza o scan de ApexFlsViolation com o caminho ponto de entrada → método de leitura → mapper DTO e o loop de ~40 campos descrito na issue. Comece rastreando o timeout do Graph Engine e o tratamento de entradas abandonadas em torno de PathScopeVisitor e dos stack frames SyntheticTypedVertex/ApexMapValue listados. O trabalho concluído deve incluir um resumo explícito ou uma saída com código diferente de zero para pontos de entrada abandonados, além de um diagnóstico ou uma correção de convergência para o caminho do mapper.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Summary

Graph Engine path evaluation never completes for a method shaped like an ordinary DTO mapper — a for loop that assigns ~40 fields from an SObject onto a new inner-class instance. Every @AuraEnabled entry point whose call graph reaches that method is abandoned with Path evaluation timed out after N ms, at any timeout value we tried.

The mapper is the main view builder for a customer community portal, so this is not an unusual corner of the codebase — it is on the hot path of most entry points.

Versions
  • @salesforce/[email protected]
  • [email protected]
  • Rule: ApexFlsViolation (sfge, DevPreview)
  • Linux: GitHub-hosted ubuntu-latest, and reproduced in node:22-bookworm with OpenJDK 17
  • Observed 2026-08-20
The most important part: it fails silently

When path evaluation times out, the entry point is abandoned and no findings are reported for it. The scan then prints:

Found 0 violations.

and exits 0.

Found 0 violations is indistinguishable from "0 violations in the parts that finished". We only discovered that ~5% of our entry points were never analysed because we had added a step that greps the run's own log for Internal execution error. Anyone gating CI on this rule without that grep is gating on an unknown subset of their code and has no way to know.

This is the part we would most like fixed, independently of the convergence bug. An abandoned entry point should be visible in the exit code or in a summary, not only in a log line.

Isolation

We bisected by modifying a copy of the tree and re-running the identical command. Baseline is unmodified.

# Change under test Elapsed Timeout?
— baseline 344s yes
A deleted 2 classes downstream of the entry point 341s yes
B replaced a per-character if/else chain with a Map lookup 352s yes
C deleted all 12 classes in the downstream call tree 360s yes
D baseline ×2 (determinism check) 342s / 348s yes
E sfge-disable-stack on the entry points 350s yes
F stubbed the body of the read method the entry point calls 63s no
G removed only the call to that read method 258s no
H stubbed the DTO mapper that read method calls 165s no
I stubbed a sibling call 347s yes
J stubbed another sibling call 345s yes
K stubbed four more sibling calls 340s yes

H is the finding. The offending method is reached as: entry point → read method → DTO mapper. Stubbing the mapper drops the run below the timeout so it cannot fire.

We then bisected inside the mapper. None of these had any effect (~340s each, i.e. the timeout still fired):

  • the one reflective read, (Id) record.getPopulatedFieldsAsMap().get('SomeField__c')
  • a call into another class returning a Boolean
  • two short-circuit && chains

So it does not appear to be any individual construct. What remains is the shape: a loop assigning ~40 fields onto a newly constructed object.

We attempted to test whether time scales with field count, but our patch produced invalid Apex for two of the three variants (the analyser ran fast and reported no errors, which we read as the class failing to parse rather than as a result). We are not claiming the field count is the cause — only that no single line in the method is, and that this is where it would be worth your engineers looking.

sfge-disable-stack does not help

Documented here for others: putting /* sfge-disable-stack ApexFlsViolation */ on the affected entry points changed nothing (E, 350s). The directive suppresses rule evaluation; the timeout happens earlier, during path expansion.

Raising the timeout does not help either

java_thread_timeout was already raised from the 30s default to 300s for an unrelated entry point. The method above does not converge at 300s and, from the shape of it, would not converge at any practical value — so the timeout is spent in full and then the entry point is dropped regardless. Lowering it trades coverage for speed; raising it trades speed for nothing.

Possibly related, same run

A different entry point in the same codebase throws, rather than timing out. It passes a Map<String, Object> into a service method:

Internal execution error while scanning entry point: <redacted>.cls:739:
  Graph Engine identified your source and sink, but you must manually verify
  that you have a sanitizer in this path. [...]
  Error and stacktrace: NullPointerException: null:
  java.base/java.util.concurrent.ConcurrentSkipListMap.computeIfAbsent(ConcurrentSkipListMap.java:1459)
  com.salesforce.graph.vertex.SyntheticTypedVertex.get(SyntheticTypedVertex.java:41)
  com.salesforce.graph.symbols.apex.ApexMapValue.apply(ApexMapValue.java:188)
  com.salesforce.graph.symbols.PathScopeVisitor.handleApexValueMethod(PathScopeVisitor.java:1487)
  com.salesforce.graph.symbols.PathScopeVisitor.afterVisit(PathScopeVisitor.java:1242)
  com.salesforce.graph.symbols.DefaultSymbolProviderVertexVisitor.afterVisit(DefaultSymbolProviderVertexVisitor.java:800)

We have also previously seen the engine throw on Map<Integer, Integer> and on Decimal.setScale, and reshaped code to avoid both.

What would help, in priority order
  1. A non-zero exit, or an explicit summary line, when entry points are abandoned. Silent under-analysis is worse than a slow scan.
  2. A diagnostic for why expansion does not converge — a path or branch count, or a verbose mode naming the expansion site. The only signal today is "it timed out", which is what forced the twelve-run bisection above.
  3. The convergence fix itself.
Outcome for us

We have removed ApexFlsViolation from our blocking gate and moved it to a nightly advisory report. The gate went from 344s to 13s. We would rather have the rule back on the gate, and will re-arm it if this is fixed.

Happy to run further bisections against a diagnostic build, or to share the method under NDA.

Linguagem predominante
TypeScript
Estrelas
241
Forks
52
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de forcedotcom/code-analyzer

Todas as issues de forcedotcom/code-analyzer

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.