UpdateAsync in Roblox: Warum zwei Speicherungen eine Änderung verlieren können

Erst den Ablauf untersuchen #

Stell dir einen gemeinsamen Übungszähler für abgeschlossene Lieferungen vor. Zwei unabhängige Handler sollen jeweils fünf hinzufügen. Beide melden ihre erledigte Arbeit, doch der Gesamtwert steigt nur einmal. Das kann passieren, wenn beide Vorschläge aus derselben alten Kopie berechnet wurden. Dieses Symptom beweist noch keine bestimmte Ursache in deinem Spiel. Dafür brauchst du ein Protokoll der Aktionen und Schreibbedingungen.

Dieser Text setzt die Anleitung zur ersten Speicherung fort, behandelt aber eine andere Frage: Der neue Wert hängt von einem Zustand ab, den ein anderer Server verändern könnte. Wir verwenden einen isolierten Übungszähler, keine Spielergeldbörse, Kaufaufzeichnung oder vollständigen Profildaten. Zahlen und Abläufe sind erfunden. Zwei echte Roblox-Server wurden für diese Beispiele nicht gestartet.

Den Ablauf mit alten Kopien zeichnen #

Schreibe fünf Zeilen: Im Speicher stehen 100; Handler A liest 100; Handler B liest 100; A schreibt 105; B schreibt seine eigenen 105. B muss keine böse Absicht haben, um die Änderung von A zu verlieren. Er ersetzt den Eintrag durch einen Vorschlag, der vor As Speicherung berechnet wurde. Zwei Additionen sollten 110 ergeben, zwei gleiche Ersetzungen lassen dagegen 105 zurück.

Bewahre die Zeichnung neben der Aufgabe auf. Sie unterscheidet einen nie gestarteten Handler, einen fehlgeschlagenen Netzwerkaufruf und erfolgreiche Schreibvorgänge auf veralteter Grundlage. Für die lokale Übung genügen Operationsname, fiktive Auftragskennung, Eingabewert und vorgeschlagenes Ergebnis. Private Spielerdaten oder Zugangsdaten sind für diese Diagnose nicht erforderlich.

Bild in voller Größe öffnen ↗

Ersetzen und Umformen sind verschiedene Absichten #

SetAsync setzt den Wert eines Schlüssels, ohne innerhalb dieses Methodenaufrufs zuvor den alten Wert zu lesen. Das passt zu einem bekannten Ersatzwert, der vom bisherigen Zustand unabhängig ist. Für eine Addition zum aktuellen Zähler ist die Berechnungsgrundlage entscheidend. Roblox empfiehlt UpdateAsync, wenn ein Schreibvorgang vom aktuellen Wert abhängt oder mehrere Server denselben Schlüssel ändern könnten.

Nur den Methodennamen auszutauschen und im Callback weiterhin vorher berechnete 105 zurückzugeben, repariert den Ablauf nicht. Der Vorschlag stammt noch aus der alten Kopie. Berechne ihn aus dem current-Argument des Callbacks. Erkläre diesen Unterschied vor dem Übertragen auf eine Inventartabelle: einen aktuellen Zustand umformen ist etwas anderes, als einen alten eigenen Schnappschuss erneut einzureichen.

Ein Callback kann erneut aufgerufen werden #

Ändert ein anderer Server den Schlüssel zwischen Lesen und Schreiben, kann UpdateAsync den vorherigen Vorschlag verwerfen und die Umformung erneut aufrufen. Ein Methodenaufruf bedeutet daher nicht genau einen Callback-Aufruf. Im erfundenen Ablauf schlägt A 105 vor, B speichert zuerst 105, und A berechnet anschließend aus 105 den neuen Vorschlag 110.

Die wiederholte Umformung sollte keinen Gegenstand erneut vergeben, kein Belohnungsereignis senden und kein externes Spielobjekt verändern. Sie berechnet den vorgeschlagenen Datensatz. Folgen im Spiel brauchen eine eigene Entscheidung auf Grundlage bestätigten Zustands. Die Gegenstandsvergabe hinter einen erfolgreichen Aufruf zu verschieben, beweist allein noch nicht, dass eine unabhängige Wiederholung derselben Geschäftsoperation durch einen anderen Handler ausgeschlossen ist.

Bild in voller Größe öffnen ↗

Eine Übungsfunktion ohne versteckten Zustand #

Unser ModuleScript CounterTransform stellt Add(current, delta) bereit. Bei fehlendem Eintrag beginnt der Zähler mit null. Es akzeptiert ganze nichtnegative Werte und eine positive Erhöhung; das Ergebnis darf höchstens eine Million betragen. Diese Regeln wurden für den Übungszähler gewählt. Anfangswert und zulässiger Bereich können in einem anderen Spiel anders sein und sind keine allgemeinen Profilregeln.

Die Funktion liefert eine neue Zahl und ändert keine äußeren Variablen. Gleiche Eingaben ergeben gleiche Ausgaben. Falsche Datentypen, negative oder gebrochene Erhöhungen und eine Überschreitung liefern nil. Die Funktion enthält weder Netzwerkaufrufe noch Wartezeiten, Belohnungen oder Spielerzugriff. Wir haben sie lokal mit Luau geprüft; das bestätigt nicht das Verhalten eines echten Roblox-Datenspeichers.

-- Pure transform for an isolated teaching counter, not a player profile.
local Transform = {}
local LIMIT = 1000000

local function validInteger(value)
    return type(value) == "number" and value == math.floor(value)
        and value >= 0 and value <= LIMIT
end

function Transform.Add(current, delta)
    if not validInteger(delta) or delta == 0 then return nil end
    if current == nil then current = 0 end
    if not validInteger(current) then return nil end
    if delta > LIMIT - current then return nil end
    return current + delta
end

return Transform

Die Umformung im isolierten Test anschließen #

Lege CounterTransform in ServerScriptService einer getrennten Test-Experience ab. Ein Server-Script holt DataStoreService, wählt den Speicher des Übungszählers und bindet das Modul über require ein. Übergib UpdateAsync einen Callback, der CounterTransform.Add(current, 5) zurückgibt. Füge der Umformung kein task.wait, Ressourcenladen oder einen anderen pausierenden Aufruf hinzu.

UpdateAsync selbst ist ein Netzwerkaufruf. Verwende pcall und prüfe seinen Rückgabewert getrennt. Ein erfolgreiches pcall bedeutet, dass kein Fehler abgefangen wurde. Wenn der Callback mit nil abbricht, bestätigt das keine gespeicherte Erhöhung. Ein Name wie „Test“ isoliert den Speicher nicht automatisch, wenn Experience und Schlüssel weiterhin Produktionsdaten enthalten.

-- Server Script in an isolated test experience only.
-- This demonstrates one numeric teaching key, not a player profile.
local DataStoreService = game:GetService("DataStoreService")
local CounterTransform = require(
    game:GetService("ServerScriptService"):WaitForChild("CounterTransform")
)
local store = DataStoreService:GetDataStore("GuidebookCounterExercise_v1")

local ok, result = pcall(function()
    return store:UpdateAsync("CounterExercise", function(current)
        return CounterTransform.Add(current, 5)
    end)
end)

if not ok then
    warn("Write response failed; outcome is not established", result)
elseif result == nil then
    warn("Update cancelled; no new saved counter was returned")
else
    print("Updated teaching counter", result)
end

Abbrechen darf nicht heimlich zurücksetzen #

Ein nil-Ergebnis des Callbacks bricht die Aktualisierung ab. Das hilft im Beispiel bei einem unerwarteten gespeicherten Typ oder einer überschrittenen Grenze. Ersetze eine fehlerhafte Zeichenkette nicht einfach durch null, um weiterzumachen. Dadurch könntest du ein Datenproblem verdecken und einen untersuchungsbedürftigen Eintrag überschreiben. Ein fehlender und ein ungültiger vorhandener Eintrag sind unterschiedliche Fälle.

Protokolliere für die Diagnose, dass das erwartete gespeicherte Ergebnis fehlt, und stoppe die weiteren Schritte dieses Übungsablaufs. Die kompakte reine Funktion liefert keine ausführlichen Ablehnungsgründe. Wenn ein Projekt solche Gründe benötigt, entwirf die Protokollierung so, dass wiederholte Callbacks keine zusätzlichen Spielaktionen erzeugen und nicht die Grundlage der nächsten Berechnung verändern.

Modell und Funktion getrennt prüfen #

Wiederhole zuerst den schlechten Ablauf: zwei Kopien von 100, zwei Vorschläge von 105 und zwei Ersetzungen. Modelliere danach die Neuberechnung: As Vorschlag vorbereiten, Bs Änderung anwenden, As alten Vorschlag verwerfen und aus 105 neu rechnen. Das Endergebnis sollte 110 sein. Dies ist ein deterministisches Modell zweier Abläufe, kein Emulator sämtlicher interner Roblox-Regeln.

Prüfe außerdem einen fehlenden Eintrag, eine normale ganze Zahl, eine Zeichenkette, einen Bruch, negative Werte, Unendlichkeit und die obere Grenze. Wiederholte gleiche Eingaben dürfen das Ergebnis nicht durch versteckten Zustand erhöhen. Eine statt einer Zahl übergebene Tabelle muss unverändert bleiben. Der lokale Test prüft diese konkreten Eigenschaften, keine Belastbarkeit eines Produktionsservers.

Callback-Wiederholung ist keine Operationswiederholung #

Die Wiederholung innerhalb einer Aktualisierung gleicht einen Vorschlag an geänderten Zustand an. Ein zweiter eigenständiger Auftrag „fünf hinzufügen“ ist eine andere Operation und kann auch mit UpdateAsync weitere fünf hinzufügen. Die Methode ist deshalb kein vollständiger Schutz gegen doppelte Belohnungen, wiederholte Aufträge oder mehrfach bearbeitete Käufe.

Für diese Geschäftsaufgabe braucht es eine definierte Operationsidentität und eine Regel, die ihren bereits abgeschlossenen Zustand zusammen mit der Datenänderung prüft. Wir implementieren diesen Mechanismus hier nicht. Der reine Zahlenwert enthält keine Operationshistorie. Gib dem nächsten Entwicklungschat diese Grenze zusammen mit dem Code weiter, damit er das Beispiel nicht für ein fertiges Geldbörsensystem hält.

Eine fehlerhafte Antwort lässt eine weitere Frage offen #

Ein Netzwerkfehler beweist nicht automatisch, dass das Backend nichts geschrieben hat. Roblox beschreibt Schreibvorgänge mit unbekanntem Ausgang: Eine erfolgreiche Antwort kann ausbleiben, obwohl die Speicherung erfolgte. Ein bedingungsloser neuer Auftrag zur Addition könnte dann die eigenständige Operation wiederholen. Das unterscheidet sich von der internen erneuten Callback-Berechnung.

Füge dem Beispiel keine endlose Wiederholungsschleife hinzu. Definiere für ein echtes System zuerst unbekannte Ergebnisse und die Reihenfolge der Operationen je Schlüssel. Wähle danach begrenzte Wiederholungen vorübergehender Fehler und passende Verzögerungen. Unser lokaler Test erzeugt keinen Roblox-Netzwerkfehler und bestätigt keine Lösung dieses Problems. Es bleibt eine getrennte Entwurfsaufgabe.

Eine Methode verwaltet kein vollständiges Profil #

Ein vollständiges Profil kann zusammengehörige Felder, Sitzungsbesitz und Metadaten enthalten. Das Beispiel mit einer Zahl zeigt nicht, wie sie beim Schreiben erhalten bleiben. Es bestimmt keinen Sitzungsbesitzer und verhindert nicht, dass ein alter Server nach dem Wechsel zu einem neuen Server seinen alten Schnappschuss speichert. Diese Aufgaben einfach UpdateAsync zuzuschreiben, würde offene Arbeit verdecken.

Verwende den Übungszähler nicht für Robux-Käufe oder echte Spielwährung. Eine Produktionslösung benötigt ein eigenes Schema, Kompatibilitätsprüfungen, Fehlerbehandlung und Belohnungsregeln. Beginne mit Roblox-Anleitungen zu player data und purchasing und prüfe danach die konkrete Umsetzung. Das kleine Experiment erklärt Umformung und ist keine Bibliothek zur Profilverwaltung.

Eine ehrliche Übergabe vorbereiten #

Teile beide Ablaufzeichnungen, den isolierten Schlüsselnamen, die Zahlenregeln und die abgeschlossenen lokalen Prüfungen. Schreibe ausdrücklich dazu, dass echte Server und Netzwerkkonflikte nicht geprüft wurden. Liste die offenen Anforderungen separat auf: unbekannter Schreibausgang, wiederholte Geschäftsoperationen, Sitzungsbesitz und Erhalt anderer Profilfelder.

Frage beim Vergleich von Lösungen, auf welchem Wert jeder Vorschlag basiert und welche Folgen außerhalb des Callbacks auftreten. Die Antwort muss einen konkreten Ablauf erklären können. Funktioniert sie nur ohne einen zweiten Schreiber, ist das Konfliktproblem noch offen. Bewahre diesen Text mit der ersten Speicheranleitung auf, um anfänglichen Speicherzugriff und spätere Koordination auseinanderzuhalten.