DogFatherGitandClaude Opus 5
9a1287aa0e
Filipe: "irgendwas klappt mit dem telefonieren nicht."
=== WIE DER FEHLER GEFUNDEN WURDE ===
Ich habe zuerst wieder die Vermittlung verdaechtigt. Stattdessen das
Protokoll des Servers gelesen -- und dort stand es die ganze Zeit:
24x anruf_start, jeder nach 7 bis 39 Sekunden beendet
im Chat danach jedes Mal: "Verpasster Anruf"
die Gegenseite schrieb: "Hab keinen Anrufeingang gehabt und
keine Benachrichtigung"
Es ging nie um Ton oder Verbindung. Es hat bei der anderen Person
schlicht nicht geklingelt.
Dieselbe Lehre wie am 06.09. ("kommt keine Mail an" -- erst fragen, OB
gesendet wurde) und am 14.09. (zwei Tage Audiowege verfolgt, waehrend
die CPU bei 98 % stand). Eine halbe Minute in der richtigen Tabelle
haette Stunden gespart.
Nebenbefund zur Messbarkeit: Das coturn-Protokoll kann die Frage gar
nicht beantworten -- es schreibt Zuteilungen bei dieser Stufe nicht
mit. Meine eigene Zuteilung von 16:35 taucht dort ebenfalls nicht auf.
Wer daraus "null Zuteilungen, also kaputt" liest, sucht am falschen
Ende. Das ist der dritte Ausgang: nicht "in Ordnung" und nicht
"kaputt", sondern "kann ich hier nicht sehen".
=== WAS WIRKLICH DEFEKT WAR ===
Die Benachrichtigung WURDE zugestellt -- `zuletzt_ok` am Geraet stand
auf genau die Anrufminute. Sie hat nur nicht geklingelt:
1. `Urgency: "normal"` STAND FEST IM TRANSPORT, fuer jede Meldung.
Auf Android entscheidet dieser Kopf, ob sofort zugestellt wird oder
bis zum naechsten Aufwachen gewartet. Im Stromsparmodus werden
daraus Minuten -- bei einem Anruf, der 120 Sekunden klingelt, ist
das ein verpasster Anruf mit Zeitstempel.
2. `renotify: false` UND `tag: d.art`. Eine zweite Meldung mit
derselben Kennung ersetzt die erste LAUTLOS. Wer ein zweites Mal
anruft, WEIL nicht abgehoben wurde, loest damit gar keinen Ton mehr
aus -- genau im wichtigsten Moment.
3. KEIN vibrate, KEIN requireInteraction. Ein stiller Kasten, der von
selbst verschwindet. In einer Hosentasche unsichtbar.
Fuer "Aufgabe ueberfaellig" ist all das genau richtig, und der
Kommentar daneben stimmte auch ("eine Meldung, die stehen bleibt, ist
eine Zumutung"). Fuer ein klingelndes Telefon ist es das Gegenteil.
Jetzt unterscheidet das Haus beides:
- eigene Kennung je Anruf, damit der zweite den ersten nicht
stillschweigend ersetzt
- renotify, vibrate (zweimal lang, wie ein Telefon),
requireInteraction
- Urgency: high und eine TTL von 150 Sekunden -- ist der Anruf
vorbei, verfaellt auch die Meldung, statt eine Stunde spaeter
nachtraeglich aufzuploppen
- alle ANDEREN Meldungen bleiben unveraendert ruhig. Das ist kein
Nebensatz: Wuerde alles vibrieren und stehenbleiben, schaltet es
nach drei Tagen jemand ab -- und dann klingelt auch der Anruf nie
wieder.
Die Dringlichkeit haengt an derselben Bedingung wie die Nachtruhe
(`art === "test" || art === "anruf"`). "Darf das nachts stoeren?" und
"darf das warten?" haben dieselbe Antwort; zwei Bedingungen waeren die,
die beim naechsten Nachschaerfen auseinanderlaufen.
=== ERREICHT ES AUCH JEMANDEN? ===
Der Service Worker ruft skipWaiting() und clients.claim() -- die neue
Fassung greift beim naechsten Oeffnen der App, ohne dass jemand etwas
tun muss.
ABER: Nachgemessen haben NEUN von fuenfzehn aktiven Zugaengen KEIN
Geraet angemeldet -- darunter eine rechte Hand und zwei Modis. Bei
ihnen kann keine Benachrichtigung ankommen, so laut sie auch waere.
Das ist kein Codefehler; das muessen die Leute einmal selbst tun.
=== GEMESSEN ===
pruef-anruf-klingelt 17/0 (neu, mit drei Gegenproben), pruef-anruf
114/0, pruef-turn-wege 15/0, pruef-meldungen 8/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
