fix(keys-tree): keep Redis hash tags in a single tree node (#308)

[claude]

Requested via Slack thread

What

Fixes #308.

Redis lets you pin related keys to the same cluster slot by wrapping part of the key name in curly braces — a "hash tag", for example {portal2:co}:sessions:42.

The keys tree builds its folders by splitting key names on the delimiter (: by default), and it did that without noticing the braces. A hash tag containing a delimiter got cut in half: {portal2:co} and {portal2:tb} collapsed into one {portal2 folder holding co} and tb}. Neither half means anything on its own, and the two portals looked like one.

Now a hash tag stays in one piece, so it becomes a single folder with its braces intact. Keys without a hash tag group exactly as before.

Before	After

Technical solution

Key names are split by a new splitKeyName helper that ignores delimiters falling inside a hash tag. It resolves the tag the same way Redis does when picking a slot: the first {, then the first } after it, and only when there is at least one character between them. Anything else — no braces, unbalanced braces, an empty {} — splits exactly as before.

Two places split key names, and both use the helper now: the tree structure itself, and the leaf label in VirtualTree. Fixing only the first would group foo:{a:b} under {a:b} while labelling it b}.

The helper's logic is deliberately duplicated inline inside constructKeysToTree, because that function is stringified into a Web Worker and cannot reference imports. An import there would throw inside the worker and silently leave the tree stale. Both copies carry a "keep in sync" comment, matching the pattern Redis Insight already uses for splitWithPrefixThreshold.

Open questions

1. Only the first brace pair is a hash tag to Redis, so a{b:c}:d:{e:f} still shows {e / f}. Treating every balanced pair as one piece would look tidier but is not what Redis means by a hash tag. Happy to switch.
2. Always on, no new setting, since it is a display-only improvement. Say the word if you'd rather it were opt-in.
3. Please confirm the leaf-label change is the behaviour you want.
4. Redis Insight's Browser tree splits hash tags the same way, in redisinsight/ui/src/helpers/constructKeysToTree.ts. Not touched here — worth a separate issue?
5. Unrelated pre-existing bug spotted nearby: KeysTree.tsx's auto-expand-to-selected-key builds parent names with a trailing delimiter that no folder name can match, and splits on the delimiter pattern as a plain string so it never splits at all when more than one delimiter is configured. Left alone. I can file it separately.

Testing

How to verify by hand

1. Connect to any Redis database and add these keys:

SET {portal2:co}:sessions:42 x
SET {portal2:co}:sessions:43 x
SET {portal2:tb}:sessions:42 x
SET user:1:name alice
SET broken{tag:key x

2. Open the database in the extension and switch the keys view to Tree view.
3. You should see {portal2:co} and {portal2:tb} as two separate folders, each with a sessions folder inside. user and broken{tag group as usual.
4. For the contrast, do the same on main: you get one {portal2 folder containing co} and tb}.
5. Optionally add a second delimiter under Settings → Delimiter (say _) and add SET {a:b_c}:d_e x. The tag {a:b_c} stays one folder while d and e split.

Automated tests

28 new cases: a table-driven spec for splitKeyName, plus tree-shape cases in the existing constructKeysToTree spec that exercise the inlined copy — the one that actually runs in the worker. Covered: the reported keys, a tag with no delimiter inside, multiple brace pairs, an empty {}, both flavours of unbalanced brace, and a two-delimiter setup.

Test Files  3 passed (3)
     Tests  34 passed (34)

Whole webviews suite: 188 passed | 3 skipped (191) files, 1406 tests passed. yarn compile is clean and lint reports no new problems on the changed files.

The before/after screenshots above are the extension's real tree components rendered in a browser against the unmocked Web Worker, so the folder structure shown is genuinely what the worker produces.