[Bug]: ChangeAwareList merges an insert one slot before a pending AddRange, corrupting list order downstream

Abierto
  • ¿Algo no está bien?
#1,225 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@dwcullop ya está trabajando en esto.

Desde el 2/11/2026.

  • #1227 de @dwcullop — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
63/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp
Área
data

Línea de trabajo

The bug is in the AddRange branch of InsertItem in src/DynamicData/List/ChangeAwareList.cs, where the minimum bound uses range.Index - 1 instead of range.Index. Start by reading that branch and the clamping code after it, then write a regression test from the issue's repro (source.Items should match the AsObservableList mirror). Done means that test passes and the existing list-change tests still pass. Leave the RangeChange list-aliasing problem for a separate issue.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
Describe the bug 🐞

When a ChangeAwareList<T> has a pending AddRange change and an item is inserted one slot before that range, InsertItem folds the item into the range and moves the range start back by one. The two are not contiguous (the element that was at range.Index - 1 now sits between them), so the emitted AddRange places the range items at the wrong positions. Anything that replays indexes (Clone, AsObservableList, Transform, Bind) ends up with a list whose order differs from the source. There is no exception: the downstream data is silently wrong.

Sort is affected independently of the source: it builds its output with its own ChangeAwareList, so a source changeset of [AddRange, Add] whose sorted positions put the single item one slot before the freshly sorted range produces a corrupted sorted output, even when the source changeset itself is correct.

Step to reproduce
using var source = new SourceList<string>();
source.Add("x");

using var mirror = source.Connect().AsObservableList();

source.Edit(list =>
{
    list.AddRange(new[] { "b", "c" }); // appended at index 1
    list.Insert(0, "a");               // index 0 == range.Index - 1
});

// source.Items: a, x, b, c
// emitted:      AddRange index 0 [a, b, c]
// mirror.Items: a, b, c, x   <-- wrong
Reproduction repository

N/A: the repro above is self-contained, and the linked PR adds regression tests.

Expected behavior

mirror.Items equals source.Items (a, x, b, c). The changeset should be [AddRange index 1 [b, c], Add index 0 a], or any other sequence that replays to the same list.

Screenshots 🖼️

N/A

IDE

N/A

Operating system

Any

Version

N/A

Device

N/A

DynamicData Version

9.5.0 and main. The merge window has been unchanged since at least 2019.

Additional information ℹ️

Root cause. src/DynamicData/List/ChangeAwareList.cs, InsertItem, AddRange branch:

var minimum = Math.Max(range.Index - 1, 0);
var maximum = range.Index + range.Count;
var isPartOfRange = index >= minimum && index <= maximum;

A pending range occupies [range.Index, range.Index + range.Count). An inserted item extends it only when it lands inside that span or directly after it, so the valid window is [range.Index, range.Index + range.Count]. The lower bound of range.Index - 1 is off by one, and the clamping and SetStartingIndex code that follows exists only to support that case.

Second case in the same branch. The seeded constructor new ChangeAwareList<T>(items) records an AddRange with index -1. Inserting into that list before CaptureChanges() merges the item one position too far to the right (insertPosition = index - (-1)). The library's own callers (ToObservableChangeSet for ObservableCollection and BindingList) capture immediately after construction, so this is only reachable by custom operators using the public type.

Scope. The other merge branches (Add + insert, Remove + remove, RemoveRange + remove) were checked with exhaustive position tests and a seeded randomized replay test (100k random edit batches) and are correct.

Separate known problem (not addressed by the fix for this issue). RangeChange<T> keeps a reference to the caller's List<T> instead of copying it (items.AsList()). A later single insert that merges into that pending range mutates the caller's list:

var mine = new List<int> { 1, 2 };
source.Edit(list =>
{
    list.AddRange(mine);
    list.Add(3);
});
// mine is now { 1, 2, 3 }

Fixing it means copying on every AddRange, which has a performance cost, so it should be decided and tracked separately.

Lenguaje dominante
C#
Estrellas
1.9k
Forks
194
Merge medio
12 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de reactivemarbles/DynamicData

Todos los issues de reactivemarbles/DynamicData

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.