E · Fehler ​

Antwort auf eine nicht verarbeitbare Anfrage. An Stelle des Keys steht reason. Der Key wird nicht zurückgegeben, daher lässt sich bei Pipelining aus dem Frame nicht erkennen, welche Anfrage fehlschlug. Deshalb ist jedes E connection-fatal. Der Server flusht E wenn möglich und schließt; offizielle Clients verwerfen ebenfalls die Session. Jeder Acquire, von dem mindestens ein Byte gesendet wurde, endet ohne definitive Antwort als Indeterminate, nie als angenommener Erfolg oder Fehlschlag.

• Diese acht Gründe sind vollständig und schließen alle die Verbindung. Raw Clients dürfen sie diagnostizieren, aber den Stream nicht resynchronisieren oder wiederverwenden.
• Offizielle Clients prüfen Key und Zeitbereiche vor dem Senden; bad_* ist kein normales API-Ergebnis.
• no_leader und not_active sind temporär, aber E hat weder owner noch key. Session verwerfen; nur noch nicht gesendete Anfragen dürfen neu versucht werden. Einen gesendeten Acquire nie automatisch wiederholen.
• M, L, no_leader und not_active gibt es nur im Cluster.
• Volle Kapazität liefert B (busy), nicht E, weil owner und key zurückgegeben werden.

Byte-Notation: op ist ein ASCII-Zeichen, und reason ist ASCII-Text (variable Länge, in der Struktur als N dargestellt). Das abschließende \n ist 0A.

Ablauf ​

E liefert Diagnoseinformationen, erlaubt aber niemals sichere Stream-Wiederverwendung. Wiederherstellbare Kapazitätsablehnung nutzt B (busy) mit owner und key.