ConcurrentDictionary.GetOrCreate can return a value that was never stored when two threads race on the same key

[matt-edmondson]

What's wrong

The ConcurrentDictionary<TKey, TVal> overload of DictionaryExtensions.GetOrCreate is a non-atomic check-then-act:

if (dictionary.TryGetValue(key, out TVal? val))
    return val;

bool result = dictionary.TryAdd(key, defaultValue);
Debug.Assert(result);
return defaultValue;

This overload exists specifically for concurrent use, but two threads can both miss in TryGetValue. One TryAdd wins. The other returns false, which fires Debug.Assert in Debug builds and is ignored in Release, and that thread returns its own defaultValue, which isn't in the dictionary.

Failure scenario

var counters = new ConcurrentDictionary<string, List<int>>();
Parallel.For(0, 1000, i => counters.GetOrCreate("k", new List<int>()).Add(i));

Every thread that loses the race appends to an orphaned list. counters["k"] ends up with fewer than 1000 entries and nothing reports the loss. In Debug builds or test runs the Debug.Assert dialog or failure fires intermittently instead.

Suggested fix

Use the atomic API the type already provides:

return dictionary.GetOrAdd(key, defaultValue);

Then drop the Debug.Assert. A lazily constructed overload (GetOrAdd(key, _ => new TVal())) would also avoid allocating a default on every hit.

Acceptance criteria

• A stress test like the one above gives every caller the same instance for a given key: counters["k"].Count == 1000, and no assert fires.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. The overload exists for concurrent callers, and under contention it hands back an instance that was never stored, so writes are lost silently in Release builds. The fix is one line (GetOrAdd), and many downstream ktsu libraries pick up this package.
• Area / suggested assignee: DictionaryExtensions.GetOrCreate, the ConcurrentDictionary overload. Maintainer: @matt-edmondson.
• Duplicates / in progress: No duplicate found and no open PR covers it. Related pattern: Concurrent CreateProfile calls for the same id can return a Profile that is never stored, so its bindings are silently lost Keybinding#112 has the same check-then-TryAdd race in CreateProfile. It is worth checking whether Keybinding calls this extension; if it does, this fix resolves both.
• Next steps: Replace the body with dictionary.GetOrAdd(key, defaultValue), drop the Debug.Assert, optionally add a factory overload, and add the Parallel.For stress test from the description.

---

Generated by Claude Code