Skip to content

Workbench var-strip rebuild signature ignores enum option identities (only counts them) #605

Description

@BorisTyshkevich

renderVarStrip's rebuild-signature computation (src/ui/workbench/variable-strip.ts, the sigNew build — moved verbatim from src/ui/app.ts, present unchanged on origin/main before the #588 phase-4 refactor) folds in each variable's control kind and enumOptions.length, but not the option identities:

return v.name + ':' + v.type + (v.optional ? '?' : '') + (v.conflict ? '!' : '')
  + ':' + c.kind + (c.enumOptions ? c.enumOptions.length : '');

Repro: a variable's inferred enum options change from ['a', 'b'] to ['c', 'd'] (same cardinality) between two renderVarStrip passes — e.g. a background schema/column reload landing between keystrokes. The signature is unchanged, so the strip does not rebuild, and the dropdown keeps offering the stale ['a', 'b'] set even though deps.params.inferredEnumOptions(...) now returns different values.

Surfaced during phase 4 of the #593 refactor umbrella's PR review (#604) — pre-existing, not introduced by that PR, and deliberately left unfixed there (a pure structural extraction is not the place for a behavior change). A comment at the signature site documents this; no regression test was added for the same reason.

Suggested fix direction: fold a stable digest of the option identities themselves into the signature (e.g. join the resolved enumOptions array), not just its length.

Metadata

Metadata

Assignees

No one assigned

    Labels

    inboxFiled mid-task; not yet triaged into the roadmap

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions