Benachrichtigungen: die Reaction laedt ein, jedes Haus bekommt sein Gesicht -- und die Videos haengen nicht mehr
Filipe, 29.09.2026: „ich will dass du die benarichtigungen
perfektionierst. dogfather und alle anderen sollen die
benachrichtigungen perfekt von dieser seite hier bekommen."
Und dazu, mit einer Bildschirmaufnahme: „wieso haengen die videos
immer."
=====================================================================
1. WARUM DIE VIDEOS HAENGEN -- zwei Zeilen, eine Rueckkopplung
=====================================================================
Die Aufnahme zeigt den YouTube-Zaehler bei 0:13 von 31:34, vier
Bilder lang unbewegt, in der Mitte der Ladering.
a) `hostMelden()` rechnete `laeuft = getPlayerState() === 1`.
Zustand 3 heisst PUFFERN -- „ich will spielen, mir fehlen
gerade Daten". Der Host meldete in diesem Moment „laeuft
nicht", und zwar sofort, weil `onStateChange` bei jedem
Zustandswechsel meldet.
b) `empfaenger()` fuegt den Host ausdruecklich hinzu, und
`folgen(d)` lief im Ereignisstrom fuer alle -- auch fuer ihn.
Seine eigene Meldung kam zurueck und traf dort auf
if (!stand.laeuft && getPlayerState() === 1) pauseVideo();
Der Host puffert eine halbe Sekunde, laeuft weiter -- und wird vom
Echo seines eigenen Pufferers angehalten. Bei einem 31-Minuten-Video
passiert das in den ersten Sekunden zuverlaessig.
Und alle Zuschauer bekamen bei JEDEM Pufferer des Hosts ein
Pause-Play-Paar. Das ist das Ruckeln, das man fuer die eigene
Leitung haelt.
GEMESSEN, NICHT HERGELEITET (mess-reaktion):
vorher Host=laeuft -> Pufferer gemeldet -> Host=pause
nachher Host=laeuft -> Pufferer gemeldet -> Host=laeuft
Drei neue Messungen, jede mit Gegenprobe:
· ein gemeldeter Pufferer haelt den Host nicht an
· ein ECHTES Anhalten (Knopf gedrueckt) haelt alle an -- sonst
waere das Erste mit kaputtem Gleichlauf bezahlt
· beim Puffern meldet der Server `laeuft=true`; ist der Pufferer
nicht herzustellen, sagt die Messung das (dritter Ausgang)
Beide Behebungen einzeln zurueckgenommen: beide Male rot.
Die erste Fassung der Gegenprobe war selbst falsch -- sie hielt das
Selbstheilen des Systems (der Host meldet alle fuenf Sekunden die
Wahrheit) fuer einen Fehler. Deshalb drueckt sie jetzt den Knopf,
statt eine Meldung zu faelschen.
=====================================================================
2. DIE REACTION LAEDT EIN
=====================================================================
Nachgemessen war `workspace-reaktion.js` STUMM: kein einziges
`benachrichtige`. Beim Einschalten lief `melden("reaktion", ...)`
ueber den Ereignisstrom -- also nur an Leute, die die Seite ohnehin
offen haben. Das Kino machte auf, und die Einladung verliess das Haus
nie. Dasselbe Muster wie bei den Bewerbungen am 23.09.
Neue Art `reaktion_live`, eigene neben `dogfather_live`: Das eine ist
sein Stream auf TikTok, das andere das Kino hier im Haus.
Eingeladen wird, wer ein Geraet hat und NICHT der Agentur gehoert
(`AGENTUR_ROLLEN` -- keine neue Liste). Nicht der, der eingeschaltet
hat. Und nicht zweimal: Eine Bremse von zwei Stunden faengt den
Neustart ab, denn das Merkmal haengt an `gestartet_am` und das wird
bei jedem Wechsel nach live neu gesetzt.
Geprueft Ende zu Ende in pruef-reaktion (+10): Sendung geht auf
Sendung, danach stehen genau fuenf Einladungen in `push_verschickt` --
rechte Hand, linke Hand, Modi, zweimal Community. Nicht der Host,
nicht die Creatorin. Einladung abgeschaltet: sechs Fehlschlaege.
=====================================================================
3. DARF DAS NACHTS KOMMEN? -- drei Antworten statt zwei
=====================================================================
Hier stand `art === "test" || art === "anruf"`, 230 Zeilen von der
Artenliste entfernt. Am 18.09. hat das eine Nacht lang alle Anrufe
verschluckt; behoben wurde damals dieser eine Fall.
GEMESSEN AM LIVE-BESTAND: `dogfather_live` ging an allen sieben
Abenden vom 22. bis 28.09. zwischen 20:28 und 21:06 raus -- jedes Mal
knapp vor der Sperre um 22 Uhr. Geht Filipe einmal um 22:05 live,
bekommt niemand etwas, und niemand erfaehrt warum.
`ruhe` steht jetzt an der ART:
"immer" (Vorgabe) 22-7 gesperrt -- Erinnerungen
"spaet" nur 1-7 -- etwas laeuft GERADE
"nie" nie -- ein Mensch wartet am Hoerer
=====================================================================
4. JEDES HAUS BEKOMMT SEIN GESICHT
=====================================================================
Im Service Worker stand fest `workspace-192.png`. Von acht Menschen
mit angemeldetem Geraet gehoeren fuenf ins Crew-Haus -- die sahen auf
jeder Benachrichtigung das Symbol des Hauses, in dem sie nicht
arbeiten.
Entschieden wird es auf dem SERVER: Im Browser stuende sonst die
verborgene Crew-Adresse in einer Datei ohne Anmeldung (der Befund vom
21.09. bei crew-haus.css) -- und es waere eine zweite Fassung der
Hausteilung. Zweistufig, beide Stufen gibt es schon: die Zielseite,
wenn sie in genau ein Haus gehoert (GEHOERT_ZU_ADRESSE), sonst
`AGENTUR_ROLLEN`.
=====================================================================
5. DAS ABZEICHEN WAR EIN KLOTZ
=====================================================================
`badge` ist das winzige Zeichen in der Statusleiste; Android benutzt
davon NUR den Alphakanal. Dort stand dasselbe `workspace-192.png` --
ein vollflaechiges Quadrat ohne Transparenz, also ein ausgefuellter
Klotz. Es stuerzt nichts ab, deshalb faellt es niemandem auf.
`assets/img/abzeichen-96.png`: der gefuellte Umriss des Huskys, weiss
auf durchsichtig, 3,5 KB. Drei Fassungen gebaut und bei ECHTER Groesse
(24 px) verglichen -- Strichbild zerfaellt, Flaeche traegt.
`server/helfer-png-alpha.mjs` liest den Alphakanal wirklich (PNG
auspacken, Zeilenfilter zuruecknehmen). Eine Pruefung auf „die Datei
gibt es" haette den Klotz nie gefunden -- die Datei gab es ja. Die
Gegenprobe ist der alte Zustand selbst: dieselbe Rechnung meldet auf
`workspace-192.png` „kein Alphakanal, Deckung 100 %".
Das Abzeichen liegt NICHT bei den App-Symbolen -- `pruef-struktur`
verlangt dort zu jedem Namen den vollen Satz und hielt es fuer eine
neue App. Der Waechter hat recht: Ein Abzeichen ist kein App-Symbol.
=====================================================================
Gemessen: mess-reaktion 0, pruef-reaktion 393/0 (+10),
pruef-push-ziel 38/0 (+27), pruef-push 24/0, pruef-push-weg 20/0,
pruef-glocke 36/0, pruef-struktur 44/0, pruef-haus-trennung 100/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
@@ -45,6 +45,19 @@ process.env.SITE_PUBLIC_LAUNCH_AT = "2020-01-01T00:00:00+01:00";
|
||||
den niemand prueft, weil das Pruefen zu lange dauert, ist ein
|
||||
ungeprueftes Verhalten. */
|
||||
process.env.REAKTION_LISTE_MAX = "3";
|
||||
/* DIE EINLADUNG DARF NICHT AN DER UHR SCHEITERN.
|
||||
|
||||
`reaktion_live` traegt die Ruheregel „spaet" -- gesperrt ist damit
|
||||
nur zwischen 1 und 7 Uhr. Liefe diese Pruefung um halb drei nachts,
|
||||
waere sie rot, ohne dass an der Software etwas kaputt ist: genau die
|
||||
Zeitbombe, die in den Hausregeln steht und die am 07.09. schon die
|
||||
Weckerpruefung getroffen hat.
|
||||
|
||||
`PUSH_SPAET_AB = 24` heisst: „gesperrt ab Stunde 24" -- die es nicht
|
||||
gibt. Damit ist „spaet" hier NIE gesperrt, zu jeder Tageszeit. Die
|
||||
Grenze selbst wird in pruef-push-ziel mit festen Stunden geprueft,
|
||||
wo sie hingehoert: als EINGABE, nicht als Annahme ueber „jetzt". */
|
||||
process.env.PUSH_SPAET_AB = "24";
|
||||
|
||||
const express = (await import("express")).default;
|
||||
const ec = express.response.cookie;
|
||||
@@ -2424,6 +2437,128 @@ melde("=== 21. Alles zuruecksetzen ===");
|
||||
});
|
||||
}
|
||||
|
||||
/* =======================================================================
|
||||
DIE EINLADUNG -- geht sie raus, und an die Richtigen?
|
||||
=======================================================================
|
||||
|
||||
Filipe, 29.09.2026: „dogfather und alle anderen sollen die
|
||||
benachrichtigungen perfekt von dieser seite hier bekommen."
|
||||
|
||||
Bis zu diesem Tag verliess die Reaction das Haus nie. Sie rief beim
|
||||
Einschalten `melden("reaktion", ...)`, und das laeuft ueber den
|
||||
Ereignisstrom -- also NUR zu Leuten, die die Seite ohnehin offen
|
||||
haben. Wer nicht hinschaut, erfuhr nichts.
|
||||
|
||||
GEPRUEFT WIRD DAS VERHALTEN, NICHT DER QUELLTEXT. Eine Textsuche
|
||||
nach „benachrichtige" waere gruen gewesen, sobald das Wort irgendwo
|
||||
steht -- auch in einem Zweig, den nichts aufruft. Hier geht die
|
||||
Sendung wirklich auf Sendung, und danach wird nachgesehen, was in
|
||||
`push_verschickt` steht.
|
||||
======================================================================= */
|
||||
melde("");
|
||||
melde("=== Die Einladung ===");
|
||||
{
|
||||
const { createServer } = await import("node:http");
|
||||
const { createECDH } = await import("node:crypto");
|
||||
|
||||
/* Ein Push-Dienst, der alles annimmt. Er muss nichts entschluesseln
|
||||
-- gefragt ist, WER eine bekommt. Dass der Inhalt unterwegs heil
|
||||
bleibt, beweist pruef-push-weg mit einem nachgebauten Browser. */
|
||||
const dienstPort = await eigenerPort(import.meta, "pruef-reaktion (Push-Dienst)", 1);
|
||||
const dienst = createServer((q, a) => {
|
||||
q.on("data", () => {});
|
||||
q.on("end", () => { a.writeHead(201); a.end(); });
|
||||
});
|
||||
await new Promise((r) => dienst.listen(dienstPort, "127.0.0.1", r));
|
||||
|
||||
/* Erst zu -- sonst waere der naechste Schritt kein UEBERGANG nach
|
||||
live, und eingeladen wird nur beim Uebergang. */
|
||||
await roh(CREW, "/workspace/api/reaktion/stand",
|
||||
{ method: "POST", keks: k.admin, rumpf: { stand: "zu" } });
|
||||
|
||||
const db2 = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
/* Je ein Geraet fuer JEDEN -- auch fuer die, die keine Einladung
|
||||
bekommen sollen. Ohne ihr Geraet waere „hat nichts bekommen" die
|
||||
Antwort auf die falsche Frage: Man wuesste nicht, ob die Auswahl
|
||||
greift oder ob nur kein Telefon da war. */
|
||||
for (const rolle of ["admin", "hand", "linke", "modi", "gast", "gast2", "creator"]) {
|
||||
const kk = createECDH("prime256v1");
|
||||
kk.generateKeys();
|
||||
db2.prepare(`INSERT INTO push_anmeldungen (person_id, endpunkt, p256dh, auth, erstellt)
|
||||
VALUES (?,?,?,?,?)`)
|
||||
.run(IDS[rolle], `http://127.0.0.1:${dienstPort}/push/${rolle}`,
|
||||
kk.getPublicKey().toString("base64url"),
|
||||
randomBytes(16).toString("base64url"), nun);
|
||||
}
|
||||
db2.close();
|
||||
|
||||
const anSendung = await roh(CREW, "/workspace/api/reaktion/stand",
|
||||
{ method: "POST", keks: k.admin, rumpf: { stand: "live" } });
|
||||
ok(anSendung.code === 200, `auf Sendung (${anSendung.code})`);
|
||||
|
||||
/* Die Einladung wird losgeschickt und nicht abgewartet -- der Knopf
|
||||
„Auf Sendung" soll sofort reagieren. Also hier warten, wo Warten
|
||||
nichts kostet. */
|
||||
await new Promise((r) => setTimeout(r, 2500));
|
||||
|
||||
const lies = () => {
|
||||
const db3 = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
const z = db3.prepare(
|
||||
`SELECT person_id FROM push_verschickt WHERE merkmal LIKE 'reaktion_live:%'`).all();
|
||||
db3.close();
|
||||
return new Set(z.map((x) => x.person_id));
|
||||
};
|
||||
const bekommen = lies();
|
||||
|
||||
const sollen = [["hand", "die rechte Hand"], ["linke", "die linke Hand"],
|
||||
["modi", "ein Modi"], ["gast", "die Community"], ["gast2", "noch jemand aus der Community"]];
|
||||
for (const [rolle, wort] of sollen) {
|
||||
ok(bekommen.has(IDS[rolle]), `${wort} wird eingeladen`);
|
||||
}
|
||||
|
||||
/* WER EINGESCHALTET HAT, BEKOMMT KEINE. Er hat gerade den Knopf
|
||||
gedrueckt; eine Einladung zu etwas, das man selbst aufgemacht
|
||||
hat, ist Rauschen. */
|
||||
ok(!bekommen.has(IDS.admin),
|
||||
"wer eingeschaltet hat, bekommt keine Einladung");
|
||||
|
||||
/* DAS ANDERE HAUS BLEIBT AUSSEN VOR. Fuer eine Creatorin gibt es
|
||||
`reaktion.html` nicht -- sie bekaeme eine Meldung, die sie auf
|
||||
ihre Startseite wirft. Eine Benachrichtigung, die nirgendwohin
|
||||
fuehrt, ist schlimmer als keine. */
|
||||
ok(!bekommen.has(IDS.creator),
|
||||
"die Agentur bekommt keine Einladung ins Crew-Kino");
|
||||
|
||||
ok(bekommen.size === 5,
|
||||
`genau fuenf Einladungen, nicht mehr (${bekommen.size})`);
|
||||
|
||||
/* ---- Die Bremse gegen den Neustart ---------------------------
|
||||
Wer aus Versehen auf „Vorbereitung" und gleich wieder auf „Auf
|
||||
Sendung" drueckt, laedt sonst zweimal ein. Fuenf Menschen
|
||||
bekaemen zwei Meldungen fuer dieselbe Sendung -- der schnellste
|
||||
Weg, dass jemand die Art abschaltet, und dann fehlt auch die
|
||||
naechste. */
|
||||
const db4 = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
const vorher = db4.prepare(
|
||||
`SELECT COUNT(*) AS n FROM push_verschickt WHERE merkmal LIKE 'reaktion_live:%'`).get().n;
|
||||
db4.close();
|
||||
|
||||
await roh(CREW, "/workspace/api/reaktion/stand",
|
||||
{ method: "POST", keks: k.admin, rumpf: { stand: "vorbereitung" } });
|
||||
await roh(CREW, "/workspace/api/reaktion/stand",
|
||||
{ method: "POST", keks: k.admin, rumpf: { stand: "live" } });
|
||||
await new Promise((r) => setTimeout(r, 2000));
|
||||
|
||||
const db5 = new DatabaseSync(process.env.WORKSPACE_DB);
|
||||
const nachher = db5.prepare(
|
||||
`SELECT COUNT(*) AS n FROM push_verschickt WHERE merkmal LIKE 'reaktion_live:%'`).get().n;
|
||||
db5.close();
|
||||
ok(nachher === vorher,
|
||||
`ein Neustart laedt nicht noch einmal ein (${vorher} -> ${nachher})`);
|
||||
|
||||
await new Promise((r) => dienst.close(r));
|
||||
}
|
||||
|
||||
melde("");
|
||||
melde(`${geprueft} Pruefungen, ${fehler} Fehler`);
|
||||
melde(fehler === 0 ? "ALLES IN ORDNUNG" : "NICHT IN ORDNUNG");
|
||||
|
||||
Reference in New Issue
Block a user