Browser syntax validator rejects valid top-level LOAD CSV query

[YGY-001]

Environment

• FalkorDB Browser: 2.4.0
• FalkorDB server: 4.20.3
• Deployment: Docker standalone

Minimal reproduction

Open any graph in FalkorDB Browser, click Clear, and paste:

LOAD CSV FROM 'file://fuzz.csv' AS row
RETURN row

The CSV file is only needed for server-side execution. The Browser syntax error appears before the query is sent.

Expected behavior

The query should pass syntax validation and be sent to FalkorDB.

Actual behavior

The Browser marks LOAD CSV as a syntax error and disables execution with:
Fix the highlighted syntax errors to run
The query is never sent to the server.

[overcut-ai]

Completed Working on "Automated Ticket Triage "

✅ Ticket triage completed for #2056. Applied labels: bug. No duplicate was identified with similarity ≥ 0.75, so no duplicate link/score applies. needs-info was not applied because the report already includes sufficient environment details, reproduction steps, and expected vs. actual behavior.

✅ Workflow completed successfully.

---

👉 View complete log

[overcut-ai]

Completed Working on "Auto Root Cause Analysis"

✅ Workflow completed successfully.

---

👉 View complete log

[overcut-ai]

Root Cause Analysis

The Browser currently uses client-side grammar diagnostics as a hard execution gate. For this issue, top-level LOAD CSV ... RETURN ... is treated as invalid by the Browser grammar path, so execution is blocked before the query is sent to FalkorDB.

Evidence

• Execution is blocked before server call
  • app/components/CypherEditor.tsx:1006-1015 — if !isQueryValid, Browser shows syntax error and returns early (no query dispatch).
  • app/components/CypherEditor.tsx:1199 — UI message: “Fix the highlighted syntax errors to run”.
• Validity is derived from grammar diagnostics
  • lib/falkordb-cypher/monacoGrammarLint.ts:74-83 — isValid currently depends on diagnostics.length === 0.
  • lib/falkordb-cypher/linter.ts:18-47 — ANTLR-based parser diagnostics feed lint results.
• Parser entry rule is strict/openCypher-based
  • lib/falkordb-cypher/grammarMapping.ts:93-94 — parse entry uses parser.oC_Cypher(), which appears stricter than FalkorDB server acceptance for this statement form.

Impacted Areas

• Main query editor run path (CypherEditor).
• Query execution from history panel (QueryHistoryPanel) via same validity gate.
• Any user query pattern accepted by FalkorDB but rejected by Browser grammar diagnostics (here: top-level LOAD CSV).

Minimal Safe Fix Suggestion

Use a targeted fallback in execution-validity computation:

• Keep diagnostics/squiggles visible.
• Allow execution when query starts with top-level LOAD CSV, even if diagnostics exist.
• Preserve current blocking behavior for all other query types.

Pseudo-diff (≈30 LOC)

--- a/lib/falkordb-cypher/monacoGrammarLint.ts
+++ b/lib/falkordb-cypher/monacoGrammarLint.ts
@@
-    const isValid = diagnostics.length === 0;
+    const isValid = computeExecutionValidity(text, diagnostics);
@@
 }
+
+/**
+ * Keep syntax squiggles, but avoid blocking execution for known
+ * client/server grammar mismatch: top-level LOAD CSV queries.
+ */
+function computeExecutionValidity(text: string, diagnostics: EditorDiagnostic[]): boolean {
+  if (diagnostics.length === 0) return true;
+
+  const trimmed = text.trimStart();
+  // Targeted fallback only for top-level LOAD CSV.
+  if (/^LOAD\s+CSV\b/i.test(trimmed)) return true;
+
+  return false;
+}

Risk Assessment

• Risk level: Low–Medium (narrow scope).
• Potential side effect: some invalid LOAD CSV statements may be sent to server (server-side validation still rejects invalid queries).
• No behavior change for non-LOAD CSV queries.

Test Recommendations

1. Unit tests for computeExecutionValidity:
   • no diagnostics => valid
   • diagnostics + LOAD CSV ... => valid
   • diagnostics + non-LOAD CSV => invalid
   • leading whitespace before LOAD CSV => valid
2. Integration tests in editor flow:
   • LOAD CSV with diagnostics still allows submit path.
   • malformed non-LOAD CSV query remains blocked.
3. Manual verification:
   • Repro query now gets sent/executed.
   • Existing syntax blocking still works for clearly broken queries.

Confidence

0.88 (high) — strong evidence from execution gate + lint pipeline and direct code references.