Repository navigation
fix(Tokenizer): suppress Create when the typed label matches a selected token - #6367
Conversation
…just ids The hasCreate duplicate check compared the typed text against selected ids. Real selections usually carry an opaque id (u1 under the label "Alice"), and the search results cannot catch the match because filteredSource pre-filters selected items out of them. Typing an existing token's label therefore offered 'Create "Alice"', which committed a second, duplicate token under a new id. Compare the trimmed query against selected labels (case-insensitive) too, in both createEntries and the stale-entry commit guard in handleAdd.
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewNo new or modified components detected. Bundle Size Summary
Accessibility AuditStatus: 1 accessibility violation(s) found — 1 serious. Tokenizer - 1 issue(s)
Visual Regression1 of 420 shot(s) changed. View the report A change here is a question, not a failure: check whether the after is the
Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
|
AI review status for this pull request. |
There was a problem hiding this comment.
This fix looks good — the duplicate check now covers selected labels (case-insensitive) both when the Create entry is offered and when a stale entry is committed, so typing the label of a token that carries a different opaque id no longer creates a duplicate. The two new regression tests cover both paths, the Tokenizer suite passes (75 tests), and the patch changeset is included. No public API or behaviour beyond suppressing that duplicate changes.
[Automated review]




Fixes #6366.
the duplicate check now also matches selected labels (case-insensitive) in both the create-entry builder and the stale-entry guard on commit, so typing an already-selected label no longer offers or commits a duplicate. label-equals-id behavior is unchanged.
2 new tests (duplicate offered, stale entry committed) fail on main and pass here. full tokenizer suite (75) green.