[aetos382]

Background

When ToNotifyCollectionChanged() is given an ICollectionEventDispatcher, only the CollectionChanged invocation is deferred to the UI thread; the internal list (listView) is
updated immediately, on the mutating thread.

As a result, when the collection is mutated from a thread other than the UI thread, the content has already moved on by the time the UI thread receives the notification, so the indices carried by the
notification no longer match the content. A consumer that reads the collection right after the notification — such as the WinUI 3 ListView, which calls IBindableVector.GetAt(index) — crashes
there with an out-of-range access (#115).

Changes

1. Defer the visible content together with the notification (the core of #115)

Added Internal/DeferredViewList<TView>. When a dispatcher is specified, the view now holds both the list as the subscribers see it (published) and a queue of not-yet-raised changes (pending):

• when a change happens, it is enqueued into pending before ICollectionEventDispatcher.Post
• the change is applied to published at the moment the notification is raised

This keeps the content of the notification and the visible content consistent at all times.
this[int] / Count / IndexOf / Contains / GetEnumerator all read published.

The following are also guaranteed:

• A dispatcher may raise some events synchronously and others asynchronously; a later event never overtakes the ones already queued (when an event is raised, all older pending changes are applied
  and raised first, in order).
• Reset does not carry items, so the writer-side content is captured as a snapshot at Post time.
• If there is no subscriber and nothing is pending, there is no notification to stay consistent with, so the change is applied on the spot. Nothing is enqueued, so a subscriber that attaches
  later does not receive past notifications.
• After unsubscribing, deferral continues while changes are still pending — switching to immediate application mid-stream would reorder the applications and corrupt the content.
• If a subscriber throws, the remaining pending changes are still applied and raised, and the exception is rethrown afterwards (AggregateException when there is more than one).
• CollectionChanged / PropertyChanged became explicit events whose add / remove are guarded by gate, so that "there is no subscriber" can be decided atomically with applying a change.

2. Index translation for position-based writes on writable views

The indexer setter, Insert and RemoveAt of ToWritableNotifyCollectionChanged() passed the view index straight through to the source collection. This is now fixed:

• On a filtered view, the index is translated back to a source index via AlternateIndexList.GetAlternateIndex (previously it was off by the number of filtered-out elements).
• While notifications are pending, the visible index is translated to the writer-side index by replaying the pending changes (Add / Remove / Move).
• An Insert at the tail of the view has no determined source index, so it is treated as AddToSourceCollection.
• An out-of-range index is rejected with ArgumentOutOfRangeException, whether or not a dispatcher is used.
• When the target element itself has been removed by a pending change, or when a pending Reset makes any index unresolvable, an InvalidOperationException is thrown, with the two reasons (element removed vs. collection reset) worded distinctly.
• The setter publishes a Replace so that the visible content is never mutated without a notification.

3. Thread check in SynchronizationContextCollectionEventDispatcher

The condition for raising synchronously was "SynchronizationContext.Current is not null", so in a process with more than one thread that has a SynchronizationContext, a mutation from a UI thread
other than the bound one was raised directly on that thread. The check is now "is Current the same context this dispatcher is bound to".

public static readonly ... Current = current.Value; was also changed to => current.Value.
Previously the Lazy was evaluated during static initialization of the type, so if a thread without a SynchronizationContext touched the type first, the result was a TypeInitializationException.

4. Notification inconsistencies (found while investigating #115)

• Move on a filtered view raised the notification with the translated indices and then fell through and raised the original one as well — notifying the same move twice, the second time with untranslated indices.
• When a filter evaluates differently at add time and at remove time, a remove notification arrives for an element that is not in the view. Since listView is unchanged, no notification must be raised. (Enqueuing a notification with an unknown index (-1) into the deferral queue makes it inapplicable at raise time, permanently breaking consistency.)
• A range remove with OldStartingIndex == -1 raised, for each element, the arguments of the whole batch, and with an uninitialized index of -1. It now raises a single-item notification carrying the position actually removed.

5. Documented the limitation of ToNotifyCollectionChangedSlim()

By design ToNotifyCollectionChangedSlim() shares the data with the source, so its visible content cannot be deferred and the same inconsistency remains. This is accepted as the trade-off for its performance, and is documented instead: the XML doc remarks and the README now state that when it is combined with a dispatcher, the collection must be mutated on the dispatcher thread.

Behavioral changes

• A view with a dispatcher holds one additional internal list for the visible content (one copy at construction time).
• With a dispatcher, a change is not reflected in Count or the indexer until the notification is raised — even as seen from the mutating thread. This is intentional; consistency with the notification is the point.
• Position-based writes on a writable view now throw InvalidOperationException for an index that cannot be resolved while notifications are pending.
• SynchronizationContextCollectionEventDispatcher.Current changed from a static readonly field to a property, so binary compatibility is not preserved.

Known bugs not fixed in this PR

• A writable view writes to the source without calling the converter when typeof(T) == typeof(TView), so Add / Insert / Remove ignore the converter even for cases that need conversion between identical types (split out into a separate branch; out of scope here).
• SynchronizationContextCollectionEventDispatcher.Current is pinned to the SynchronizationContext of whichever thread reads it first, and Lazy<T> caches exceptions too, so if a thread without a context reads it first, it throws InvalidOperationException forever for the rest of the process.
  (Making it a property avoids the static-initialization failure, but the pinning and the cached exception remain.)
• ToNotifyCollectionChangedSlim() still carries the same inconsistency as described above; only documentation was added.

[Copilot]

Pull request overview

Defers synchronized-view state alongside dispatched notifications to keep UI-visible content and event indices consistent.

Changes:

• Adds deferred view state and writable-index translation.
• Fixes dispatcher thread detection and notification inconsistencies.
• Adds documentation and extensive regression tests.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
README.md	Documents slim-view threading limitations.
src/ObservableCollections/ICollectionEventDispatcher.cs	Corrects synchronization-context dispatching.
src/ObservableCollections/Internal/DeferredViewList.cs	Implements deferred visible state.
src/ObservableCollections/ObservableList.OptimizeView.cs	Documents slim-view behavior.
src/ObservableCollections/SynchronizedViewList.cs	Integrates deferral and index translation.
tests/ObservableCollections.Tests/DeferredNotificationConsistencyTest.cs	Tests notification-state consistency.
tests/ObservableCollections.Tests/DeferredNotificationTest.cs	Covers deferred behavior and writes.
tests/ObservableCollections.Tests/MultipleUiThreadTest.cs	Tests multiple UI contexts.
tests/ObservableCollections.Tests/NotifyCollectionChangedContractTracker.cs	Adds notification contract validation.
tests/ObservableCollections.Tests/QueuedCollectionEventDispatcher.cs	Adds queued dispatcher fixture.
tests/ObservableCollections.Tests/QueuedSynchronizationContext.cs	Adds synchronization-context fixture.
tests/ObservableCollections.Tests/TestUiThread.cs	Adds simulated UI thread.
tests/ObservableCollections.Tests/ToNotifyCollectionChangedTest.cs	Cleans unused imports.
tests/ObservableCollections.Tests/WritableViewIndexTranslationTest.cs	Tests writable index translation.

Suppressed comments (3)

src/ObservableCollections/SynchronizedViewList.cs:1167

• When the converter rejects the source write (setValue == false) and no dispatcher was supplied, this condition skips Publish, so the notify collection changes its visible item without raising CollectionChanged. Emit the synthetic Replace for the inline path as well; Publish already supports it.

                    if (deferred != null)

src/ObservableCollections/SynchronizedViewList.cs:1076

• Breaking as soon as the callback's own event is reached leaves any newer pending changes untouched. If this callback's subscriber throws, the exception is rethrown and can abort the dispatcher pump before those callbacks run, so remaining pending changes are not applied and raised before rethrow. Drain all changes already pending at callback entry before propagating collected exceptions.

            if (ReferenceEquals(applied, e)) break;

src/ObservableCollections/SynchronizedViewList.cs:1174

• Suppressing this synthetic notification assumes SetToSourceCollection will always deliver the source Replace. An ObservableList.CollectionChanged subscriber registered before the view can throw before the view handler runs; the setter then throws after listView was changed, and this queued change is applied silently with no source notification to replace it. Ensure the synthetic update is notified or rolled back when the source update fails.

                            IsInvokeCollectionChanged = !setValue, // the Replace of the source carries the same content

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[Copilot]

🟡 Changes recommended

A filter-change race can update the wrong visible element, and IList.Add returns incorrect insertion indices while notifications are queued in both writable implementations.

2 open issues

• Filter changes can make the cached view index stale · New
• IList.Add returns an incorrect index with queued notifications · New

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human assessment is needed because converter-driven source mutations can overwrite the wrong item, and notification publication can deadlock with concurrent filter resets.

No open issues 🎉

2 resolved since last review

• Filter changes can make the cached view index stale
• IList.Add returns an incorrect index with queued notifications

_{Review effort: Balanced}