Bug: kbdactions-enumerable-ctor-bypasses-duplicate-guard

[drmoisan]

• Work Mode: full-bug

Summary

KbdActions<TKey, UClass, VDelegate> enforces a duplicate-registration guard in Add, but the
IEnumerable<UClass> constructor bypasses it entirely. Production code registers a duplicate through
that constructor, which makes a subsequent lookup for that key throw InvalidOperationException.

Environment

(not provided in potential file)

Steps to Reproduce

(not provided in potential file)

Expected Behavior

(not provided in potential file)

Actual Behavior

(not provided in potential file)

Logs / Screenshots

(not provided in potential file)

Impact / Severity

(not provided in potential file)

Source

From: docs/features/potential/2026-08-07-kbdactions-enumerable-ctor-bypasses-duplicate-guard.md

[drmoisan]

Additional finding: the defect is dormant, not live (from issue #454 preparation research)

Preparation research for issue #454 (epic #136, child F11) characterized this defect precisely
against QuickFiler/Controllers/QfcCollectionController.cs and found that the production
registration path never reaches it.

Exact current behavior

1. QfcCollectionController.WireUpKeyboardHandler (QfcCollectionController.cs:1254) builds
   new KbdActions<Keys, KaKey, Action<Keys>>(new List<KaKey> {...}) with three entries at
   :1265-1272: ("Collection", Keys.Up), ("Collection", Keys.Down), ("Collection", Keys.Down).
2. The IEnumerable constructor KbdActions(IEnumerable<UClass> list)
   (QuickFiler/Controllers/KbdActions.cs:26-29) performs no duplicate check — it is a plain
   new List<UClass>(list). Construction succeeds; the collection holds all three entries. The
   duplicate check exists only in the two Add overloads at KbdActions.cs:90-104 and :106-121.
3. Find(Keys.Down) (KbdActions.cs:53-69) matches two entries, falls through to default:, and
   throws InvalidOperationException with the message
   "Multiple sources have registered actions for Key Down. SourceId list [Collection and Collection]"
   (built at :64-66 via SentenceJoin).
4. The indexer this[Keys.Down] (:36-38) throws through Find.
5. FindIndex(Keys.Down) (:71-88) logs the same message via logger.Error at :85, then throws.
6. ContainsKey(Keys.Down) (:49) returns true. FilterKeys(Keys.Down) (:51) returns both
   entries without throwing.

Why it is dormant

WireUpKeyboardHandler has no caller anywhere in the solution — verified by a repository-wide
reference search. Production wires keys through WireUpAsyncKeyboardHandler
(QfcCollectionController.cs:1275-1280) and RegisterAsyncKeyActions (:1282-1291), which register
Keys.Up and Keys.Down exactly once each.

The severity recorded on this issue should be downgraded accordingly.

Suggested scheduling

WireUpKeyboardHandler is one of twelve unreachable members now tracked in issue #468. Removing that
dead code would resolve this issue as a side effect. The two should be scheduled together, and #468
is the better place to start.

Scope note

Issue #454 does not fix this. Under epic #136's no-behavior-change NFR it will add a
characterization test asserting the current behavior — that the constructor does not throw, that
FilterKeys(Keys.Down) returns two entries, and that Find(Keys.Down) throws
InvalidOperationException.