Den Chat am Laufen halten, wenn ein Handy schläft

Der Agent von Mythex kann minutenlang an einer Anfrage arbeiten, und du schaust vielleicht vom Handy aus zu. Das sperrt sich, wechselt Apps und die Netzwerkverbindung ändert sich dabei. Zwei Fehler haben das schiefgehen lassen. Im einen behandelte der Chat jedes Signal „Die Seite ist wieder sichtbar“ als Beweis, dass seine Verbindung tot war, und blieb in einer Schleife bei „Connecting…“ hängen. Im anderen bekam ein Handy, das die erste Antwort eines neuen Chats verschlafen hatte, nach dem Aufwachen nur die ersten Teile zu sehen, bis man die Seite manuell neu lud. Beide sind behoben.

Wie der Chat einen laufenden Zug verfolgt

Während der Agent arbeitet, hält der Chat einen Stream von unseren Servern offen. Jeder Schritt – ein Gedanke, ein Tool-Aufruf, ein Stück der Antwort – kommt als Event an. Bricht der Stream ab, verbindet sich der Chat neu, und der Server spielt die letzten Events aus einem Puffer erneut ab, der die letzten 120 Sekunden hält. Wenn der Zug endet, fragt der Chat außerdem den Server nach der gespeicherten Historie und gleicht ab, was er angezeigt hat, mit dem, was gespeichert wurde. Dieser letzte Schritt fängt alles auf, was der Stream verpasst hat.

Um bei Stille eine lebende von einer toten Verbindung zu unterscheiden, sendet der Server alle 15 Sekunden ein kleines „Ping“.

Fehler 1: Das Aufwachen hat einen gesunden Stream gekillt

Browser sagen einer Seite, wenn sie wieder sichtbar wird: nach einem Tab-Wechsel, nach dem Entsperren des Bildschirms. Wir haben das als Anlass genommen, die Verbindung zu prüfen, und in der Praxis den Stream abgebrochen und neu verbunden, weil wir annahmen, er sei im Hintergrund gestorben.

Auf Handys und in eingebetteten Browsern feuern diese Events viel öfter, als Streams abbrechen: bei jedem Tab-Wechsel, jedem Entsperren und in manchen eingebetteten Browsern etwa alle paar Sekunden. Jedes davon brach einen völlig gesunden Stream ab. Der Chat verband sich neu, spielte ab, wurde wieder abgebrochen und landete bei „Connecting…“. Dann meldete er, der Zug sei beendet, obwohl der Agent noch arbeitete.

Die Lösung: den Stream danach beurteilen, ob er spricht

Der Chat merkt sich jetzt, wann der Stream jedes Projekts zuletzt irgendetwas empfangen hat, Events und die 15-Sekunden-Pings gleichermaßen. Ein Signal „wieder sichtbar“ bricht nur einen Stream ab, der 25 Sekunden lang still war: länger als das Ping-Intervall plus einen langsamen Netzwerkweg, sodass ein lebender Stream nie betroffen ist. Tests prüfen, dass ein Ping als Lebenszeichen zählt und dass ein Stream, der gerade gepingt hat, nicht als tot gilt.

Die Regel, die wir daraus gezogen haben: Die Sichtbarkeit einer Seite sagt etwas über die Seite aus, nicht über die Netzwerkverbindung. Frag also die Verbindung selbst.

Fehler 2: Nach dem Aufwachen des Handys nur eine halbe Antwort

Den konnten wir im iOS-Simulator jedes Mal reproduzieren:

1. Starte einen neuen Chat und sende eine Anfrage, die eine Weile dauert.
2. Lass das Handy den Build verschlafen.
3. Komm zurück, wenn der Zug beendet ist und der zweiminütige Wiederholungspuffer abgelaufen ist.

Der Chat zeigte die ersten Blöcke der Antwort als fertig markiert an und blieb so, bis man die Seite neu lud.

Warum

Ein neuer Chat hat noch keinen Thread, also keine gespeicherte Unterhaltung, bis die erste Nachricht einen erzeugt. Das geschieht in der Sendefunktion, nachdem Senden den Abgleichschritt bereits erfasst hatte, der noch dachte, es gebe keinen Thread. Am Ende des ersten Zugs in einem neuen Chat sah der Abgleich also keinen Thread und kehrte stillschweigend zurück, ohne etwas anzufordern.

Meist fiel das nicht auf, weil der Stream den ganzen Zug ohnehin geliefert hatte. Ein Handy aber, das den Zug verschlafen hatte und nach Ablauf des 120-Sekunden-Puffers zurückkam, konnte die fehlenden Events nicht mehr aus dem Stream holen. Und der Abgleich, der die Lücke hätte schließen sollen, war nie gelaufen.

Die Lösung

• Senden teilt dem Abgleich mit, zu welchem Thread der Zug gehört. So wird der erste Zug eines neuen Chats wie jeder andere abgeglichen. Wenn du inzwischen einen anderen Chat geöffnet hast, wenn die Antwort zurückkommt, wird das Ergebnis verworfen, statt im falschen Chat zu erscheinen.
• Ein fehlgeschlagener Abgleich wird wiederholt. Ein Handy, das auf einer schlechten Verbindung aufwacht, kann feststellen, dass der Zug vorbei ist, und ihn dann nicht abrufen können. Das wird jetzt gemerkt, und der Chat fragt erneut, sobald der Tab wieder angezeigt wird oder das Netz zurückkommt.
• „Worked for“ ist ehrlich. Jede Antwort zeigt, wie lange der Agent gearbeitet hat. Hat der Tab die End-of-Turn-Nachricht des Servers nie gesehen, füllte er die Zeit früher aus seiner eigenen Uhr auf, die ab dem Senden lief, bis das Handy aufwachte, samt Zeit der Abwesenheit. Diese Angabe ist jetzt als Schätzung gekennzeichnet und wird durch die gespeicherte Dauer ersetzt, sobald die Historie eintrifft.

Was wir daraus gelernt haben

• Teste auf dem Gerät, das Menschen tatsächlich benutzen, so wie sie es benutzen. Beide Fehler lagen in der Lücke zwischen „ein Stream, der funktioniert“ und „ein Handy in der Hosentasche“.
• Eine Rückfalloption, die nie läuft, ist keine Rückfalloption. Der Abgleichschritt existierte genau für diesen Fall und hat ihn stillschweigend übersprungen.
• Wiederhole auch die Wiederherstellung. Der Moment, in dem ein Handy aufwacht, ist oft der Moment, in dem seine Verbindung am schlechtesten ist.
• Zeige keine Vermutung als Tatsache. Eine Dauer von der falschen Uhr ist schlechter als keine. Kennzeichne sie oder ersetze sie.

Dieselbe Arbeit hat auch einige Dinge aufgeräumt, die du während eines laufenden Zugs siehst: Shell-Schritte werden mit dem Befehl beschriftet, der die eigentliche Arbeit erledigt, und nicht mit cd. Screenshots im Chat behalten die linke obere Ecke der Seite und passen in die Spalte. Ein neues Projekt übernimmt seinen generierten Namen ohne Neuladen.

Wenn du eine eigene App für Handys baust, behandeln unsere Guides wie du eine für Mobilgeräte optimierte Web-App baust und native Apps im Vergleich zu Progressive Web Apps die Grundlagen. Mehr über den Chat selbst steht in der Chat-Dokumentation.