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

[wandering-walnut]

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/cli@2.146.3
• code-analyzer@5.15.0
• 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.

[nikhil-mittal-165]

Hi @wandering-walnut,

Thanks for the incredibly thorough writeup — the bisection work here made this much easier to reason about. You've pinpointed three separate problems: the silent abandonment, the non-convergence itself, and the Map<String, Object> NPE. We're digging into all three with the team internally, and I'll post updates here as we make progress. Really appreciate the offer to help test — we'll likely circle back on that.