VALUES-list completion stops giving useful hints once the first value is a string literal #2

Closed
opened 2026-05-28 14:43:39 +01:00 by oliversturm · 1 comment
oliversturm commented 2026-05-28 14:43:39 +01:00 (Migrated from github.com)

Repro (simple mode):

  • Schema: Customers(id serial PK, Name text, Age int, SerNo serial)
  • Type insert into Customers values ('Oli' — hints/completions for the next positional value are no longer meaningful.

If the first literal entered doesn't immediately resolve to the first expected column's type role, the completion probe appears to abandon the per-column type inference for the rest of the list.

Entry points to look at:

  • completion_probe_in_modesrc/dsl/walker/mod.rs:293
  • caller: src/completion.rs:335

Expected

Schema-aware per-position type hints should continue for the remaining values, regardless of whether the first literal type-matches the first expected column.

**Repro (simple mode):** - Schema: `Customers(id serial PK, Name text, Age int, SerNo serial)` - Type `insert into Customers values ('Oli'` — hints/completions for the next positional value are no longer meaningful. If the first literal entered doesn't immediately resolve to the first expected column's type role, the completion probe appears to abandon the per-column type inference for the rest of the list. Entry points to look at: - `completion_probe_in_mode` — `src/dsl/walker/mod.rs:293` - caller: `src/completion.rs:335` ### Expected Schema-aware per-position type hints should continue for the remaining values, regardless of whether the first literal type-matches the first expected column.
oliversturm commented 2026-05-29 11:23:11 +01:00 (Migrated from github.com)

Fixed in fa5d0dc.

Re-characterised on investigation. The report's hypothesis (per-column inference is abandoned when the first literal doesn't match the first column's type role) was not the actual cause — the behaviour was not literal-type-specific. Probing values ('Oli', values (42, and values (3.5 all reproduced identically.

Real root cause. The ambient-hint ladder's bottom rung (ambient_hint_core_in_mode, src/input_render.rs:751) parsed schemalessly (parse_command_in_mode), while every higher rung already ran schema-aware. With the schema absent, the type-blind grammar closes the insert … values (…) tuple after one value, so the "Next:" hint pointed at ) when — with the remaining columns known — the correct next token is ,. The same schemaless parse also accepted wrong-arity closed tuples as complete, so the hint read "submit with Enter" for inputs the schema-aware parse rejects.

Fix. The fallback rung now calls parse_command_with_schema_in_mode(input, cache, mode) — no extra walk, the call site already held the cache. The whole ladder is now schema-consistent.

Verified the friendly arity diagnostic is not masked: in advanced mode it fires at a higher rung and still wins (locked by a new guard test).

Tests: ambient_hint_between_values_points_to_comma_not_close_paren, ambient_hint_after_last_value_points_to_close_paren, advanced_mode_wrong_arity_insert_keeps_friendly_diagnostic_over_fallback, plus three re-baselined typing-surface snapshots. Documented in ADR-0022 Amendment 3.

Spun off: #17 (simple-mode wrong-count tuples miss the friendly arity diagnostic advanced mode shows) and #18 (the sibling schemaless gate in completion.rs:336) — both surfaced during this fix's review and will be tackled as immediate follow-up.

Fixed in `fa5d0dc`. **Re-characterised on investigation.** The report's hypothesis (per-column inference is abandoned *when the first literal doesn't match the first column's type role*) was not the actual cause — the behaviour was **not literal-type-specific**. Probing `values ('Oli'`, `values (42`, and `values (3.5` all reproduced identically. **Real root cause.** The ambient-hint ladder's bottom rung (`ambient_hint_core_in_mode`, `src/input_render.rs:751`) parsed **schemalessly** (`parse_command_in_mode`), while every higher rung already ran schema-aware. With the schema absent, the type-blind grammar closes the `insert … values (…)` tuple after one value, so the "Next:" hint pointed at `)` when — with the remaining columns known — the correct next token is `,`. The same schemaless parse also accepted wrong-arity *closed* tuples as complete, so the hint read "submit with Enter" for inputs the schema-aware parse rejects. **Fix.** The fallback rung now calls `parse_command_with_schema_in_mode(input, cache, mode)` — no extra walk, the call site already held the cache. The whole ladder is now schema-consistent. **Verified the friendly arity diagnostic is not masked:** in advanced mode it fires at a higher rung and still wins (locked by a new guard test). Tests: `ambient_hint_between_values_points_to_comma_not_close_paren`, `ambient_hint_after_last_value_points_to_close_paren`, `advanced_mode_wrong_arity_insert_keeps_friendly_diagnostic_over_fallback`, plus three re-baselined typing-surface snapshots. Documented in ADR-0022 Amendment 3. **Spun off:** #17 (simple-mode wrong-count tuples miss the friendly arity diagnostic advanced mode shows) and #18 (the sibling schemaless gate in `completion.rs:336`) — both surfaced during this fix's review and will be tackled as immediate follow-up.
Sign in to join this conversation.