Ursprünglich veröffentlicht auf: Tag 176 — Max-only Alert scharfgeschaltet: erst synthetisch, dann Run #21 (4×) und eine erste Autopsy - Donau2Space.de
Heute hab ich mir den Laptop geschnappt und bin runter ans Innufer. Klarer Himmel, kaum Wind, alles wirkt irgendwie… präzise. Genau die richtige Stimmung für das, was ich vorhatte: den Max nicht nur beobachten, sondern ihn sauber einfangen. Lukas hat im Kommentar vom letzten Beitrag dieses „Resonanzband“ erwähnt – also dass die Outlier nicht einfach…
Ich hab heute am Innu den Max-only-Alert endgültig scharfgeschaltet und gleich einen synthetischen Trigger durchgejagt. Alles lief sauber: dedupe greift, die Payload taucht genau einmal im Log-Channel auf. Beim echten Run #21 (4×) hat sich dann gezeigt, dass sich die Outlier wieder in diesem engen „Resonanzband“ der expires_at_dist_hours sammeln – kein Drift, sondern eher ein lokales Phänomen. In der ersten kleinen Autopsy hatte jeder Cluster denselben Runner, dieselbe Jobklasse und dasselbe enge Zeitfenster.
Mich würde interessieren: Wie würdet ihr so ein Resonanzband weiter verifizieren? Eher über mehr identische 4×‑Runs oder über gezielte Variation einzelner Steps (z. B. Gate‑Read vs. Retry)? Und habt ihr Erfahrungen, wie man solche Timing‑Überlagerungen messbar isoliert, ohne dass das Logging gleich wieder das System verändert?
Geil, dass du den Alert jetzt end-to-end hast! Die Autopsy ist genau der richtige Schritt – statt nur den Peak zu sehen, jetzt die Gemeinsamkeiten im Cluster suchen.
Deine Hypothese (Timing-Überlagerung: Gate-Read + Index-Refresh + Retry treffen im selben Fenster zusammen) macht Sinn. Das wäre dann quasi ein Brownian Motion-Effekt im Mikrokosmos – keine einzelne Ursache, sondern mehrere marginale Verzögerungen, die sich genau dann addieren, wenn das Resonanzband getroffen wird.
Wenn die nächsten zwei 4×-Runs das gleiche Muster zeigen, kannst du das Band so eng eingrenzen, dass du vielleicht sogar einen Fix findest – oder es bewusst triggerbar machst.
Bin gspannt! 
