Nested `LOAD CSV` planned inconsistently causing timeouts on some plans

Neo4j version

• Neo4j Docker image: 2026.07.1
• Cypher: 25
• Runtime comparison: slotted versus pipelined

Reproduction

Place this three-line file at import/fuzz.csv:

alpha,beta
one,two
three,four

Start with an empty database and create a small graph:

UNWIND range(0, 127) AS i
CREATE (:l2:l10:l4:l3:l9:l11:l1:l7:l8 {id: i});

Run the following query twice, changing only the runtime hint:

CYPHER runtime=slotted
UNWIND ['D','8AFd','DpUDbbF1R'] AS alias0
FOREACH (elem4565 IN range(3, 9) | CREATE (:l2 {k10: elem4565}))
FOR alias1 IN [-1094018090,-1119469534]
FOREACH (elem5121 IN ['A', 'B', 'C'] | CREATE (:l11 {k10: elem5121}))
LOAD CSV FROM 'file:///fuzz.csv' AS alias2 FIELDTERMINATOR ','
FILTER (size(coll.insert(CASE WHEN range(11, 3, -3) IS :: LIST<ANY> THEN range(11, 3, -3) ELSE [] END, 0, 0)) >= 0)
FOREACH (elem4288 IN ['A', 'B', 'C'] | CREATE (:l8 {k5: elem4288}))
OPTIONAL MATCH (), (:l2&l10&l4&l3&l9&l11&l1&l7&l8)
WHERE (alias0 IS :: STRING | INTEGER)
  AND COUNT {
    LET alias3 = coll.min(CASE WHEN range(1, 10, 2) IS :: LIST<ANY> THEN range(1, 10, 2) ELSE [] END),
        alias4 = coll.min(CASE WHEN alias2 IS :: LIST<ANY> THEN alias2 ELSE [] END),
        alias5 = localdatetime('2024-01-01T00:00:00')
    LOAD CSV FROM 'file:///fuzz.csv' AS alias6
  } >= 0
RETURN percentileDisc(toFloatOrNull(alias1), 0.5) AS alias7
SKIP 0 LIMIT 0;

Assessment

This is a runtime-specific performance regression report, not a crash or a correctness-mismatch report. Pipelined being faster by itself would not prove a bug. The evidence here is the controlled magnitude and the isolated trigger:

• On a 128-node graph with the three-row CSV, pipelined completed in about 4–5 seconds and returned zero rows because of LIMIT 0.
• slotted exceeded 50 seconds in the same setup and was terminated by the 20-second client timeout used by the differential harness.
• Replacing only the inner LOAD CSV in the COUNT subquery with an equivalent three-row UNWIND reduced slotted execution to about 2 seconds.

Expected behavior

The slotted runtime should not spend more than an order of magnitude longer on this small, zero-row-result query solely because the nested COUNT subquery contains LOAD CSV. It should complete within a reasonable time, rather than exposing only a client transaction-timeout error.

Notes

The timeout is a symptom of the slow execution, not a database crash. The query is valid and the issue is the slotted runtime's excessive work in this nested COUNT + LOAD CSV shape. Since pipelined is generally expected to be faster, the report should be evaluated as a slotted performance regression rather than as a claim that the two runtimes must have identical timings.