Race Conditions in Async UI Code vermeiden

1. Warum Race Conditions in Async UI Code entstehen

Race Conditions in Async UI Code entstehen, weil JavaScript keine Garantie dafür gibt, dass mehrere gleichzeitig gestartete asynchrone Operationen auch in der Reihenfolge ihres Starts abschließen. Ein Request, der später gestartet wird, kann früher antworten als ein Request, der bereits vorher lief, etwa weil der Server für die zweite Anfrage schneller antwortet oder das Netzwerk für die erste Anfrage kurzzeitig überlastet ist. Ohne explizite Vorkehrung verarbeitet der UI-Code beide Antworten in der Reihenfolge ihres Eintreffens, nicht in der Reihenfolge ihrer ursprünglichen Auslösung.

Das wird in UI-Kontexten besonders sichtbar, weil Nutzerinteraktionen wie Tippen, Klicken oder Scrollen typischerweise mehrere asynchrone Operationen kurz hintereinander auslösen, bevor die erste überhaupt abgeschlossen ist. Race Conditions in Async UI Code sind deshalb kein Randfall, sondern die Regel bei jeder Interaktion, die schneller erfolgt, als der Server antworten kann. Ein Suchfeld, ein Autovervollständigungs-Widget oder ein Filter-Dropdown sind die typischen Orte, an denen dieses Problem zuerst auffällt, meist erst im produktiven Betrieb bei echten Nutzern mit unterschiedlichen Netzwerkbedingungen.

2. Das klassische Beispiel: Suchfeld mit veralteten Antworten

Das Standardbeispiel für Race Conditions in Async UI Code ist ein Suchfeld, das bei jedem Tastendruck einen neuen Request an den Server schickt. Tippt ein Nutzer schnell „re“, dann „rea“, dann „react“, werden drei Requests praktisch gleichzeitig gestartet. Antwortet der Server auf „re“ aus irgendeinem Grund langsamer als auf „react“, überschreibt die veraltete Antwort für „re“ das bereits korrekt angezeigte Ergebnis für „react“, sobald sie eintrifft, weil der naive Code einfach jede ankommende Antwort in den State schreibt.

Das Ergebnis für den Nutzer ist verwirrend und schwer zu reproduzieren: Die Suchergebnisse springen scheinbar zufällig zwischen unterschiedlichen Suchbegriffen hin und her, obwohl der Nutzer längst mit dem Tippen fertig ist. Weil das Timing von Netzwerklatenz abhängt, tritt der Fehler in lokalen Entwicklungsumgebungen mit konstant schneller Antwortzeit selten auf und zeigt sich oft erst in Produktion, wo Netzwerkbedingungen variieren.

// BUGGY: no protection against out-of-order responses
let searchResults = [];

async function onSearchInput(query) {
  const response = await fetch(`/api/search?q=${query}`);
  searchResults = await response.json(); // last response to arrive wins, not last query typed
  renderResults(searchResults);
}

3. Sequenznummern-Pattern: nur die neueste Anfrage zählt

Das robusteste Muster gegen Race Conditions in Async UI Code ist ein monoton steigender Zähler, der bei jedem neuen Request erhöht wird. Vor dem Verarbeiten einer Antwort prüft der Code, ob die Sequenznummer, mit der der Request gestartet wurde, noch der aktuellsten bekannten Sequenznummer entspricht. Ist die Antwort älter als die zuletzt gestartete Anfrage, wird sie verworfen, unabhängig davon, wann sie tatsächlich eintrifft.

Dieses Muster funktioniert unabhängig davon, ob der zugrunde liegende Request abbrechbar ist oder nicht, weil die Entscheidung rein auf dem Vergleich von Zahlen basiert und nicht auf dem tatsächlichen Stoppen der Netzwerkanfrage. Das macht das Sequenznummern-Pattern zur einfachsten und zuverlässigsten ersten Verteidigungslinie gegen Race Conditions, selbst wenn eine echte Netzwerk-Abbrechung aus irgendeinem Grund nicht möglich ist.

// FIXED: sequence number ensures only the latest request's response is applied
let latestRequestId = 0;

async function onSearchInput(query) {
  const requestId = ++latestRequestId;
  const response = await fetch(`/api/search?q=${query}`);
  const results = await response.json();

  if (requestId !== latestRequestId) {
    return; // a newer request has since been started, discard this stale response
  }
  renderResults(results);
}

4. AbortController als netzwerkseitige Ergänzung

Das Sequenznummern-Pattern verhindert zwar, dass veraltete Antworten den UI-State überschreiben, es stoppt aber nicht die eigentliche Netzwerkanfrage im Hintergrund. Für viele Fälle reicht das aus, aber bei teuren Server-Operationen, etwa einer aufwendigen Datenbankabfrage pro Suchanfrage, lohnt es sich, die veraltete Anfrage zusätzlich mit AbortController tatsächlich abzubrechen, statt sie nur zu ignorieren. Das reduziert Serverlast und verkürzt die Zeit, bis der Server für die aktuellste Anfrage frei wird.

Die Kombination aus Sequenznummer und AbortController ist in der Praxis die robusteste Lösung gegen Race Conditions in Async UI Code: Die Sequenznummer schützt zuverlässig gegen das Überschreiben des UI-State, selbst wenn der Abbruch aus irgendeinem Grund fehlschlägt oder der Server ihn ignoriert, während AbortController zusätzlich unnötige Serverlast und Netzwerk-Traffic vermeidet.

// Combine sequence number with AbortController for full protection
let latestRequestId = 0;
let currentController = null;

async function onSearchInput(query) {
  const requestId = ++latestRequestId;
  currentController?.abort(); // cancel the previous in-flight request
  currentController = new AbortController();

  try {
    const response = await fetch(`/api/search?q=${query}`, {
      signal: currentController.signal,
    });
    const results = await response.json();
    if (requestId === latestRequestId) {
      renderResults(results);
    }
  } catch (error) {
    if (error.name !== 'AbortError') throw error;
  }
}

5. Closures und veralteter State als zweite Fehlerquelle

Eine zweite, subtilere Quelle von Race Conditions entsteht durch Closures, die auf veralteten State verweisen. Wenn eine asynchrone Callback-Funktion eine Variable aus dem umgebenden Scope einschließt, bevor der State sich ändert, arbeitet die Callback nach ihrer Auflösung mit dem Wert, der zum Zeitpunkt der Erzeugung galt, nicht mit dem aktuellen Wert. In Komponenten mit häufigen State-Updates führt das zu Situationen, in denen ein Callback fälschlicherweise mit einer alten Version eines Formularfelds oder Zählers arbeitet.

Der zuverlässige Schutz dagegen ist, innerhalb der asynchronen Callback niemals direkt auf eingeschlossene Variablen zuzugreifen, sondern den aktuellen State über eine Referenz zu lesen, etwa ein Ref-Objekt in React oder eine reaktive Variable in Vue und Alpine, die immer den aktuellen Wert liefert, unabhängig davon, wann die Closure erzeugt wurde. Diese Technik trennt den Zeitpunkt der Closure-Erzeugung vom Zeitpunkt des tatsächlichen Zugriffs auf den Wert.

// BUGGY: closure captures the counter value at creation time
function startAutoSave(counter) {
  setTimeout(() => {
    saveToServer(counter); // stale value if counter changed before the timeout fired
  }, 2000);
}

// FIXED: read the current value through a ref at call time
function startAutoSave(counterRef) {
  setTimeout(() => {
    saveToServer(counterRef.current); // always reads the latest value
  }, 2000);
}

6. Race Conditions bei parallelen State-Updates

Neben Netzwerk-Antworten können auch parallele Schreibzugriffe auf denselben State Race Conditions erzeugen, insbesondere wenn mehrere asynchrone Operationen denselben State auf Basis eines zuvor gelesenen Werts aktualisieren. Ein klassisches Beispiel ist ein Zähler, der aus dem aktuellen Wert plus eins berechnet wird, während zwei Erhöhungen quasi gleichzeitig ausgelöst werden. Liest beide Operationen denselben veralteten Ausgangswert, bevor eine der beiden ihr Ergebnis schreibt, geht eine der beiden Erhöhungen komplett verloren.

Die Lösung liegt darin, State-Updates funktional zu formulieren, sodass jede Aktualisierung explizit auf dem tatsächlich aktuellen Wert basiert, statt auf einem zuvor gelesenen Snapshot. In React etwa löst die funktionale Form von setState, die den vorherigen State als Parameter entgegennimmt, dieses Problem strukturell, weil die Aktualisierung garantiert auf dem zum Zeitpunkt der tatsächlichen Ausführung gültigen State aufbaut, nicht auf einem möglicherweise veralteten, zuvor eingeschlossenen Wert.

7. Race Conditions gezielt reproduzieren und testen

Race Conditions sind notorisch schwer zu reproduzieren, weil sie vom exakten Timing zweier oder mehrerer asynchroner Operationen abhängen. Für zuverlässige Tests lohnt es sich, die Reihenfolge der Promise-Auflösung explizit zu steuern, statt sich auf echte Netzwerklatenz zu verlassen. Ein Test-Double, das kontrollierbare Verzögerungen simuliert, macht es möglich, gezielt den Fall zu erzeugen, in dem eine später gestartete Anfrage vor einer früher gestarteten auflöst.

Ein bewährtes Muster ist, die zu testende Funktion mit einer Mock-Implementierung von fetch zu versehen, die für bestimmte Suchbegriffe eine steuerbare Verzögerung einbaut. Der Test löst dann bewusst die zweite Anfrage vor der ersten auf und prüft, ob der finale UI-State dem Ergebnis der zuletzt gestarteten Anfrage entspricht, nicht dem der zuletzt aufgelösten. Ein solcher Test schlägt zuverlässig fehl, sobald das Sequenznummern-Pattern fehlt oder fehlerhaft implementiert ist.

// Test that deliberately resolves the older request after the newer one
test('discards stale search response', async () => {
  const responses = {
    re: delayedResolve({ items: ['react', 'redux'] }, 100),
    react: delayedResolve({ items: ['react'] }, 10), // resolves first despite being newer
  };
  fetchMock.mockImplementation((url) => responses[extractQuery(url)]);

  const search = createSearchController();
  search.query('re');
  search.query('react');

  await flushAllTimers();
  expect(getRenderedResults()).toEqual(['react']); // not the stale ['react', 'redux']
});

8. Wie Frameworks das Problem teilweise lösen

Moderne Data-Fetching-Bibliotheken wie React Query oder SWR lösen Race Conditions in Async UI Code weitgehend automatisch, indem sie intern bereits Sequenznummern-ähnliche Mechanismen und Request-Deduplizierung implementieren. Wer diese Bibliotheken einsetzt, bekommt den Schutz gegen veraltete Antworten meist ohne eigenen Code, muss aber verstehen, dass dieser Schutz nur für die von der Bibliothek verwalteten Requests gilt, nicht für eigenständigen, direkt geschriebenen Fetch-Code außerhalb dieser Abstraktion.

Frameworks wie React, Vue oder Alpine.js selbst lösen das Problem nicht automatisch, weil sie kein eingebautes Konzept von Request-Reihenfolge besitzen. Sie liefern lediglich die Bausteine, Refs, reaktive Referenzen oder Effekt-Cleanup-Funktionen, mit denen sich das Sequenznummern-Pattern oder eine Kombination mit AbortController sauber implementieren lässt. Die eigentliche Absicherung gegen Race Conditions bleibt in jedem Fall Aufgabe des Anwendungscodes, nicht des Frameworks selbst.

9. Lösungsansätze im Vergleich

Die folgende Tabelle vergleicht die vorgestellten Ansätze nach Schutzwirkung und Aufwand.

Für die meisten Anwendungen ist die Kombination aus Sequenznummer und AbortController der beste Kompromiss aus Zuverlässigkeit und Kontrolle, ohne eine zusätzliche Bibliothek einzuführen.

10. Zusammenfassung

Race Conditions in Async UI Code entstehen, weil Antworten nicht garantiert in der Reihenfolge eintreffen, in der ihre Requests gestartet wurden. Das Sequenznummern-Pattern ist die einfachste und zuverlässigste Verteidigung, weil es veraltete Antworten anhand eines simplen Zahlenvergleichs verwirft, unabhängig davon, ob der zugrunde liegende Request tatsächlich abgebrochen werden kann.

Kombiniert mit AbortController lässt sich zusätzlich unnötige Netzwerklast vermeiden. Eine zweite, subtilere Fehlerquelle sind Closures, die veralteten State einschließen, statt den aktuellen Wert über eine Referenz zu lesen. Wer beide Muster konsequent anwendet und Race Conditions gezielt mit kontrollierten Verzögerungen testet, reduziert eine der häufigsten und am schwersten zu debuggenden Fehlerklassen in interaktiven UIs erheblich.

11. FAQ: Race Conditions in Async UI Code vermeiden