5d9c8cd37764f5e4f3e5ed36aed900cf34be1537
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
e349de0040 |
Sendeprotokoll fuer Benachrichtigungen: "ich bekomme nichts" ist jetzt beantwortbar
Beim Nachsehen zu Dienes Meldung ist aufgefallen, dass ueber den Versand selbst nichts festgehalten wird. Im Protokoll standen nur push_angemeldet und push_abgemeldet -- kein Wort darueber, ob je etwas verschickt wurde, an wie viele Geraete, und warum nicht. Von neun Aufrufstellen wertete genau eine den Rueckgabewert aus; die anderen acht warfen ihn weg. Sagt jemand "ich bekomme nichts", liess sich also nicht nachsehen, OB gesendet wurde -- dieselbe Falle wie am 06.09. in VanVans Shop, wo zwei Stunden in die Zustellung ermittelt wurden, bevor jemand fragte, ob die Mails abgeschickt waren. Sie waren es, alle, nachweisbar in einer Abfrage. zuletzt_ok reicht dafuer nicht: Es sagt, wann zuletzt irgendetwas ankam -- nicht was, nicht an wen sonst, und nichts ueber die Faelle, in denen gar nicht erst gesendet wurde. Genau die (abgeschaltet, Ruhezeit, kein Geraet) sind die haeufigste Antwort auf die Frage. Neue Tabelle push_versand: Zeit, Person, Art, Grund, Geraete, zugestellt. Festgehalten wird JEDER Ausgang, auch der, bei dem nichts hinausging -- ein Protokoll, das nur Erfolge kennt, kann die Frage nicht beantworten, fuer die es angelegt wurde. Das Protokoll sitzt als Huelle um den Versand, nicht in ihm: Sieben Ausgaenge einzeln zu protokollieren waere eine Liste zum Pflegen, und der achte, den jemand naechstes Jahr einbaut, umginge sie still -- so sind am 11.09. die Spalten beim Tabellenumbau verschwunden. So steht ein neuer Ausgang ohne Zutun mit drin. Aufraeumen nach 30 Tagen, neben dem bestehenden Aufraeumen von push_verschickt. Gemessen statt geschaetzt: rund 16 Chat-Nachrichten am Tag an bis zu acht angemeldete Geraete -- ein paar tausend Zeilen im Monat. Das Schreiben kann den Versand nicht aufhalten (try), meldet sich aber, wenn es scheitert: ein Protokoll, das heimlich nichts schreibt, ist schlimmer als keins. pruef-push-eilig 13 -> 20. Darunter die Gegenprobe, dass auch das NICHT-Senden protokolliert wird, und dass ein Fehlschlag nicht als zugestellt gilt. Datenbank vorher gesichert und die Sicherung geprueft (integrity_check, 20 Personen, 10 Anmeldungen lesbar). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
73f9b24793 |
Benachrichtigungen wecken das Telefon wieder: Urgency je Art
Diene hat gemeldet: "Die Benachrichtigungen werden nicht angezeigt,
wenn neue Nachrichten reinkommen. Erst, wenn man die App oeffnet."
Alles Messbare war gruen: Der Service Worker zeigt die Meldung bei
geschlossener App (pruef-push-zu, 13 Pruefungen), jede Anmeldung im
Haus stand auf fehler = 0, der Push-Dienst quittierte mit 201. Nur
den Kopf auf der Leitung hat nie jemand gemessen:
Urgency: normal
Beide Dienste behandeln das ausdruecklich als "darf warten".
Android/FCM haelt solche Meldungen zurueck, solange das Telefon
doest, und stellt sie zu, wenn es aufwacht -- typischerweise beim
Entsperren oder Oeffnen der App. Apple/APNs nennt es "verzoegert,
gebuendelt oder gedrosselt". Das ist Dienes Satz, Wort fuer Wort,
und es stand als Vorgabe im eigenen Quelltext.
zuletzt_ok konnte das nie zeigen: Es beweist, dass der DIENST
angenommen hat, nicht dass das GERAET etwas angezeigt hat.
Bis hierher hing die Dringlichkeit an der Ruheregel (dringend =
regel === "nie"), mit der Begruendung, "darf das nachts stoeren?"
und "darf das warten?" haetten dieselbe Antwort. Haben sie nicht:
Ein Chat um 3 Uhr soll schweigen, um 14 Uhr aber nicht vierzig
Minuten liegen bleiben. Jetzt zwei Felder -- in DERSELBEN Zeile
derselben Artenliste, damit sie nicht auseinanderlaufen koennen.
10 von 19 Arten sind eilig (Anruf, Chat, Erwaehnung, Support, Hilfe,
Termin, Wecker, zweimal Live, Probe). Die anderen neun duerfen
warten -- waere alles eilig, waere nichts mehr eilig.
DIE FALLE BEIM BEHEBEN: dringend steuerte auch die Haltbarkeit
(TTL 150). Ein einfach auf "dringend" gestellter Chat waere nach
150 s verfallen -- wer sein Telefon drei Minuten aus hat, haette die
Nachricht GAR nicht mehr bekommen. Aus "zu spaet" waere "nie"
geworden. Deshalb sind eilig und kurzlebig getrennt; kurzlebig
bleibt genau beim Anruf und der Probe.
Der alte Name kracht jetzt, statt still "normal" zu liefern.
pruef-push-eilig.mjs (neu, 13 Pruefungen): die Entscheidung je Art
unabhaengig notiert statt aus der Artenliste abgelesen, jede Art
muss eine Entscheidung haben, und der Kopf wird durch
benachrichtige() hindurch an einem nachgebauten Push-Dienst
gemessen. Gegenprobe gelaufen: ohne das Feld meldet sie
"chat_nachricht geht mit Urgency: normal hinaus", 4 Fehler.
Die Uhr ist dort eine Eingabe, keine Annahme -- die Zeitzone wird so
gewaehlt, dass der Lauf immer auf 12 Uhr faellt, sonst waere die
Pruefung nachts rot ohne Befund.
pruef-anruf-klingelt 25 -> 26. Dabei aufgefallen: Eine ihrer
Pruefungen war gruen, obwohl die Zeile aus dem Code verschwunden war
-- sie stand nur noch in einem Kommentar, der die alte Fassung
zitiert. Quelltextpruefungen lesen dort jetzt ohne Kommentare.
Co-Authored-By: Claude Opus 5 <[email protected]>
|