Concurrent CreateProfile calls for the same id can return a Profile that is never stored, so its bindings are silently lost

[matt-edmondson]

What's wrong

ProfileManager.CreateProfile (Keybinding/Services/ProfileManager.cs:~45-54) does a check-then-act and ignores the result of TryAdd:

if (_profiles.TryGetValue(normalizedId, out Profile? existingProfile)) return existingProfile;
Profile newProfile = new(normalizedId, name.Trim(), description);
_profiles.TryAdd(normalizedId, newProfile);   // result ignored
return newProfile;

When two threads create the same id at once, the thread whose TryAdd fails still returns its own Profile, which is not in _profiles. The XML doc promises "the created profile, or existing profile if it already exists", and CLAUDE.md describes the services as thread-safe.

Failure scenario (reproduced)

Two threads behind a Barrier both call CreateProfile("p", "P"), repeated 2000 times. In 297 trials the returned instance was not ReferenceEquals to GetProfile("p").

Every SetChord on the orphaned instance is invisible to GetProfile, and SaveAsync never persists it.

This is separate from #109, which is about concurrent BindChord mutating a profile's inner Dictionary. This race is at the profile-map level.

Suggested fix

return _profiles.GetOrAdd(normalizedId, _ => new Profile(normalizedId, name.Trim(), description));

Acceptance: a concurrency test, with N threads calling CreateProfile for the same id, asserts that every returned instance is the one stored.

[matt-edmondson]

Triage

• Category: Bug
• Priority: Medium. It breaks the documented thread-safety guarantee and silently loses bindings, but it needs two threads creating the same profile id at the same moment. That is uncommon in practice, although the reproduction shows it is easy to hit when it does happen.
• Area: ProfileManager.CreateProfile
• Suggested assignment: Keybinding maintainer, services area
• Duplicates: None. The issue already distinguishes this from Concurrent BindChord calls corrupt a profile's bindings, despite the "thread-safe services" guarantee #109 (inner Dictionary race). Related to RenameProfile clears the description when none is passed, and replaces the Profile object so held references silently stop persisting #113 (RenameProfile swap). All three are ProfileManager concurrency holes and are worth fixing in one pass.
• In progress: No open PR covers this.

Notes: The GetOrAdd fix is a one-liner and low risk. GetOrAdd's factory can run more than once under contention, but only one result is stored and returned to every caller, which is exactly the fix needed here.

---

Generated by Claude Code