Minecraft und Discord: Was passiert bei fehlenden Meldungen?
Wenn Discord nicht erreichbar ist, sollte eine Benachrichtigungsintegration das Minecraft-Event weiterlaufen lassen, noch relevante Meldungen aufbewahren und Zustellprobleme für das Team sichtbar machen. Vereinbart dieses Verhalten, bevor ihr das Plugin beauftragt. Eine erfolgreich versendete Nachricht in einer Vorführung belegt noch kein verlässliches Verhalten bei einem Ausfall.
Hier geht es um Meldungen in eine Richtung: von einem Paper-Server über einen eingehenden Webhook in einen Discord-Kanal. Beispiele sind Anmeldeübersichten, Rundenergebnisse und Statusmeldungen. Befehle aus Discord, Kontoverknüpfungen und der Abgleich von Rollen sind nicht Teil dieses Entwurfs. Dafür braucht ihr eigene Regeln für Identität und Berechtigungen. Die folgenden Anforderungen sind ein Spezifikationsvorschlag, keine von uns getestete Mineando-Implementierung.
Legt fest, wo das verbindliche Ergebnis steht
Angenommen, ein Turnierplugin speichert das Ende einer Runde und meldet den Sieger in Discord. Der gespeicherte Turnierstand sollte verbindlich sein. Eine fehlende Nachricht darf weder die Runde wiederholen noch eine Belohnung erneut vergeben oder den Sieger ändern.
Formuliert zwei getrennte Abnahmekriterien: „Das Rundenergebnis wurde gespeichert“ und „Die Meldung wurde zugestellt“. Das Team muss beide Zustände prüfen können. Eine Nachricht in der Warteschlange ist noch keine zugestellte Nachricht.
Bei einer überschaubaren Integration hilft diese Trennung mehr als eine lange Funktionsliste. Nehmt sie in die Abnahmekriterien für das Plugin auf. Legt außerdem fest, wer ein Ergebnis berichtigen oder seine Meldung erneut senden darf. Erneutes Senden betrifft ausschließlich die Benachrichtigung, niemals die zugrunde liegende Spielaktion.
Gebt jeder Meldung einen nachvollziehbaren Ablauf
Verlangt eine stabile Ereigniskennung, den Erstellungszeitpunkt, eine Referenz auf das Ziel, eine Ablaufregel und einen Zustellstatus. Sinnvolle Zustände sind ausstehend, zugestellt, abgelaufen und zur Prüfung. Ein erneuter Versuch verwendet dieselbe Ereigniskennung, statt ein neues logisches Ereignis anzulegen.
Sollen Ergebnisse einen Neustart überstehen, braucht die Lösung dauerhafte Speicherung. Speichert die Anwendung Ergebnisse in einer Datenbank, kann sie das Ergebnis und die ausstehende Benachrichtigung beispielsweise in derselben Transaktion erfassen. Ist das nicht möglich, verlangt einen Abgleich, der gespeicherte Ergebnisse ohne Benachrichtigung findet. Der Entwickler muss den gewählten Ansatz erläutern und vorführen. Eine ausschließlich im Arbeitsspeicher liegende Warteschlange erfüllt keine Anforderung an dauerhafte Speicherung.
Trennt diese Arbeit vom Server-Tick. Paper empfiehlt, langsame Netzwerkarbeit außerhalb des Hauptthreads auszuführen, und warnt zugleich vor unsicheren Weltzugriffen aus asynchronen Aufgaben. Die Umsetzung muss beide Grenzen beachten. Siehe die Paper-Dokumentation zur Aufgabenplanung.
Ein zusätzlicher Thread braucht ebenfalls Grenzen. Vereinbart die maximale Warteschlangengröße und das Verhalten bei Überlauf. Für dieses Turnierbeispiel bleiben die offiziellen Ergebnisse gespeichert, während das Team einen sichtbaren Zustellfehler erhält und den Abgleich durchführen kann. Eine wichtige ausstehende Ergebnismeldung darf nicht stillschweigend einer gewöhnlichen Statusmeldung weichen.
Unterscheidet Verzögerungen von Konfigurationsfehlern
Discord verlangt eine dynamische Auswertung seiner Ratenbegrenzungen. Bei HTTP 429 gilt die Wartezeit aus Retry-After oder retry_after; eine universelle Versandquote gehört nicht fest in den Code. Liefert ein Webhook 404, soll er nicht weiter versucht werden. Grundlage ist die Discord-Dokumentation zu Rate Limits.
Für vorübergehende Netzwerkfehler vereinbart ihr begrenzte Wiederholungen mit steigenden Wartezeiten und einer zufälligen Streuung. Definiert sowohl die maximale Zahl der Versuche als auch das Höchstalter einer Nachricht. Beim Erreichen einer Grenze kommt die Meldung je nach Zweck zur Prüfung oder läuft ab. Eine endlose Wiederholungsschleife ersetzt keinen Betriebsablauf.
Falsche Zugangsdaten, ungültige Nachrichten und nicht erreichbare Ziele brauchen eine sichtbare Diagnose. Die Übergabedokumentation muss erklären, welche Fehler das Ziel pausieren und wie das Team den Versand nach einer Korrektur fortsetzt. Protokolle enthalten hilfreiche Kennungen und Fehlerklassen, aber keine Webhook-Geheimnisse. Für Proben verwendet ihr getrennte Ziele, damit keine Testmeldungen im echten Community-Kanal erscheinen.
Geht ehrlich mit möglichen Duplikaten um
Die Webhook-API bietet mit wait=true eine stärkere Versandbestätigung und liefert die erstellte Nachricht zurück. Speichert deren Kennung, wenn sie vorliegt. Beschrieben ist das unter Execute Webhook.
Trotzdem bleibt folgender Fall möglich: Discord nimmt die Nachricht an, doch die Verbindung bricht vor der Antwort an eure Anwendung ab. Diese kann daraus nicht schließen, dass nichts veröffentlicht wurde. Ein neuer Versuch kann eine zweite Meldung erzeugen. Eine interne Ereigniskennung erleichtert die Untersuchung; dieselbe Kennung im Nachrichtentext sorgt beim Ziel nicht automatisch für eine Entfernung von Duplikaten.
Vereinbart eine Regel für diesen unklaren Zustand. Bei einer gewöhnlichen Ergebnismeldung kann ein gut erkennbares Duplikat vertretbar sein. Bei einer folgenreichen Ankündigung kann zuerst eine Prüfung durch das Team nötig sein. Keine dieser Regeln darf das Spielergebnis oder dessen Belohnungen erneut ausführen. Akzeptiert das Versprechen „genau einmal“ nur mit einem nachgewiesenen Mechanismus und klar beschriebenen Fehlergrenzen.
Bestimmt, welche Nachrichten verfallen
Nach einem Ausfall können Meldungen technisch korrekt und trotzdem nutzlos sein. „Die nächste Runde beginnt in zwei Minuten“ sollte nicht erscheinen, wenn diese Runde längst läuft. Ein offizielles Ergebnis kann dagegen auch später hilfreich sein, sofern der ursprüngliche Ereigniszeitpunkt erkennbar bleibt.
Eine kleine Tabelle reicht als Ausgangspunkt:
| Meldung | Vorgeschlagenes Verhalten nach der Wiederherstellung |
|---|---|
| Runde startet bald | Verfällt zum Start dieser Runde. |
| Offizielles Rundenergebnis | Bleibt zur Prüfung oder späteren Zustellung mit ursprünglicher Zeit erhalten. |
| Wiederholte Statusmeldung | Der neueste Stand ersetzt ältere ausstehende Meldungen, sofern kein Verlauf benötigt wird. |
Das sind redaktionelle Beispiele und keine Discord-Vorgaben. Entscheidet gemeinsam mit der Eventleitung. Erhaltet die Reihenfolge, wo sie relevant ist, und klärt, ob ein späteres Ergebnis eine frühere fehlgeschlagene Meldung überholen darf. Nach der Störung wird die Warteschlange kontrolliert abgearbeitet, statt den Kanal mit unkommentierten alten Nachrichten zu füllen.
Prüft die Fehlerfälle vor der Abnahme
Nutzt einen isolierten Testserver und ein kontrolliertes Testziel oder einen simulierten HTTP-Dienst. Überlastet Discord nicht absichtlich, um Ratenbegrenzungen auszulösen. Lasst den Entwickler folgende Fälle ausführen und belegen:
- Die Zielantwort verzögern: Das Spiel läuft weiter, die Meldung bleibt ausstehend.
- Eine Ratenbegrenzung simulieren: Der nächste Versuch hält die vorgegebene Wartezeit ein.
- Mit ausstehenden Ergebnissen neu starten: Die vereinbarten Datensätze bleiben erhalten und die Verarbeitung wird fortgesetzt.
- Eine Annahme mit verlorener Antwort simulieren: Die Regel für unklare Zustellungen wird sichtbar angewendet.
- Das Testziel entfernen: Wiederholungen stoppen und das Team sieht einen behebbaren Fehler.
- Erst nach Rundenbeginn wiederherstellen: Der abgelaufene Countdown wird nicht gesendet.
- Die vereinbarte Warteschlange füllen: Die Überlaufregel greift, ohne Spielaktionen erneut auszuführen.
Haltet Versionen, Eingaben, Soll- und Ist-Ergebnisse, Warteschlangenzustände und Zeitpunkte fest. Bis zur tatsächlichen Durchführung lautet der Status „nicht ausgeführt“. Messt das Serververhalten im vereinbarten Szenario; diese Checkliste liefert keinen Benchmark zur Spielerzahl.
Bestimmt für die Eventprobe eine Person, die Anzahl und Alter ausstehender Meldungen sowie ungelöste Fehler überwacht. Plant einen Eskalationsweg außerhalb des ausgefallenen Versandkanals. Klärt, wer Sendungen pausieren, unklare Zustellungen abgleichen und erneute Sendungen freigeben darf.
Für eine individuelle Minecraft-Integration bringt ihr Ereignistypen, Ziel, erwartete Lastspitzen, Ablaufregeln und die Fehlercheckliste ins Projektgespräch mit. Mineando bietet kostenpflichtige Entwicklung mit individuell vereinbartem Umfang und Angebot. Wartung und Betreuung während des Events werden gesondert vereinbart.
