Graph DSL ignores unconsumed tokens — a typo'd clause keyword silently runs the statement with default semantics

[emanzx]

Version / build tested against

origin/main @ 2886155

Deployment mode

Origin — single node (local)

Engine(s) involved

Graph (overlay)

Summary

The graph DSL parser seeks its clause keywords (DEPTH, LABEL, DIRECTION, IN, ...) anywhere in the token stream and never checks that every token was consumed. Any token that is not a recognized clause keyword is silently ignored. The sharp edge is typo'd clause keywords: DEPTS 3 (for DEPTH 3) silently runs with the default depth, and LABELS 'follows' (for LABEL 'follows') silently runs an unfiltered traversal — the query returns a plausible result computed with different semantics than the user wrote. Value validation inside a recognized clause works (DIRECTION sideways is refused by name), so this is the complementary hole: the clause keyword itself is not validated as reachable/consumed.

Steps to reproduce

CREATE COLLECTION g (id INT PRIMARY KEY, n TEXT) WITH (engine = 'graph');

-- Value validation inside a recognized clause works:
GRAPH TRAVERSE FROM 1 DIRECTION sideways IN g;
-- ERROR: parse error: DIRECTION must be one of in, out, both — found 'sideways'   (correct)

-- But arbitrary garbage tokens are accepted anywhere:
GRAPH TRAVERSE FROM 1 SIDEWAYS IN g;         -- runs, default traversal
GRAPH TRAVERSE FROM 1 BANANA PHONE IN g;     -- runs, default traversal

-- And a typo'd clause keyword silently changes semantics:
GRAPH TRAVERSE FROM 1 DEPTS 3 IN g;          -- runs with DEFAULT depth, the 3 is ignored
GRAPH NEIGHBORS OF 1 LABELS 'follows' IN g;  -- runs UNFILTERED — the label filter is dropped

Expected behavior

After clause extraction, any unconsumed token is a parse error naming the offending token (e.g. parse error: unexpected token 'DEPTS' in GRAPH TRAVERSE), matching how an unknown clause value is already refused by name. A typo can change a query's meaning only if the parser accepts it.

Actual behavior

Unrecognized tokens anywhere between recognized clauses are discarded without diagnosis. Statements with typo'd clause keywords execute with default semantics (default depth, no label filter, default direction) and return success.

What actually happened? (check all that are true)

• Acknowledged/committed data was lost, corrupted, or silently wrong — silently-wrong query results (unfiltered/mis-parameterized traversals); stored data intact
• The server crashed, hung, or failed to start
• A security or isolation boundary was crossed
• Core functionality is broken with no acceptable workaround
• A workaround exists (rewrite the query, avoid one path, etc.)

Proposed severity

SEV-3 — Medium: feature wrong, but operational and a workaround exists

Reproducibility

Always — every attempt

Last known-good version / commit (if a regression)

Never worked — the recent clause-value validation covers values after recognized keywords; unconsumed-token detection has not existed.

Environment & logs

Linux x86_64, release build from a fresh data directory, trust mode, pgwire via psql 16. No relevant server log lines.

Before submitting

• I searched existing issues and this is not a duplicate.
• I reproduced this on a released tag or a current main build (not a stale local branch).
• This is not a security vulnerability (those go to a private advisory).