Highlights
Die Nutzung erfasst jetzt jede Stunde, die dein Abrechnungszeitraum berührt. Die Credit-Summe auf deiner Seite „Usage & Limits“ deckt den Zeitraum also ab der ersten Sekunde ab. Organisationen haben den Feinschliff erhalten, der letzte Woche noch fehlte: Die hinzugefügte Person wird benachrichtigt, der Owner, über dessen Plan abgerechnet wird, ebenfalls, und die Rollenauswahl erklärt endlich, was eine Rolle darf. Zudem haben wir das Dashboard überarbeitet und Meldungen neu geschrieben, die eher für uns als für dich formuliert waren.
Was ist neu
Jede Stunde deines Abrechnungszeitraums zählt
Dein Abrechnungszeitraum beginnt genau in der Sekunde deiner Registrierung. Die Nutzung wird in festen Intervallen gemessen. Diese beiden Punkte stimmen fast nie überein, daher muss die Berechnung an den Übergängen exakt sein.
Das ist sie jetzt. Ein Zeitraum wird in vollständige Intervalle mit der feinsten noch verfügbaren Auflösung für jeden Abschnitt unterteilt, nichts wird geteilt, nichts doppelt gezählt. Alle drei Stellen, die Nutzungsdaten auslesen, nutzen dieselbe Implementierung, was die eigentliche Lösung darstellt. Drei Kopien derselben Logik führen zwangsläufig dazu, dass eine davon fehlerhaft ist.
Was dir auffallen wird: Jeder Wert auf „Usage & Limits“ fällt etwas höher aus als letzte Woche. Derselbe Traffic, lückenlosere Erfassung. Niemand überschreitet durch diese Änderung ein Plan-Limit. Dieselbe Logik steuert dein Kontingent, daher war die Genauigkeit in beide Richtungen wichtig.
Niemand tritt einer Organisation unbemerkt bei
Organisationen wurden letzte Woche eingeführt. Du konntest Teammitglieder hinzufügen, ihnen eine Rolle zuweisen und sie Keys nutzen lassen, die das Unternehmen bezahlt. Was du nicht tun konntest, war, sie darüber zu informieren. Der Hinweis unter dem Formular forderte dazu auf, das selbst zu erledigen.
Jetzt gibt es zwei E-Mails. Die hinzugefügte Person erhält eine mit dem Namen der Organisation, wer sie hinzugefügt hat, was ihre Rolle erlaubt und wo sie die Organisation verlassen kann, falls sie das nicht erwartet hat. Der Owner erhält eine, sobald jemand beitritt, da die Keys der Organisation über seinen Plan abgerechnet werden und eine weitere Person, die Credits verbraucht, für ihn relevant ist. Keine der Mails geht an die Person, die den Button geklickt hat. Du brauchst keine Bestätigung für deine eigene Aktion.
Die Benachrichtigung an den Owner wird in beiden Fällen ausgelöst: bei direktem Hinzufügen und bei einer Einladung, die beim ersten Login angenommen wird, wenn also niemand aktiv hinzugefügt hat, sondern die Person sich selbst anmeldet.
Auch Rollen erklären sich nun von selbst. Eine Zeile unter dem Auswahlfeld passt sich deiner Auswahl an, und die Spalte „Role“ enthält einen Tooltip für alle drei Rollen, einschließlich Owner. Zwischen „Member“ und „Admin“ wählen zu müssen, ohne die Berechtigungen zu kennen, führt dazu, dass Admin-Rechte leichtfertig vergeben werden.
Ein Schritt zum Hinzufügen von Teammitgliedern
E-Mail-Adresse eingeben, auf „Add“ klicken. Wer FourA bereits nutzt, tritt sofort bei. Wer FourA noch nicht nutzt, erhält eine Einladung per Mail und ist ab dem ersten Login dabei. Derselbe Button, dieselbe Bestätigung, dasselbe Ergebnis. Die Seite beschreibt beide Abläufe in einem Satz, anstatt anzugeben, welcher Fall auf die eingegebene Adresse zutrifft.
Dieser zweite Dialog ist weg, und genauso die Antwort, die dir früher verriet, ob für eine Adresse hier bereits ein Account existiert. Ob eine beliebige E-Mail bei uns registriert ist, beantworten wir nicht.
Das Dashboard schreibt nicht mehr ins Log
"Failed to fetch organizations" ist eine Zeile für uns. Sie tauchte direkt vor dir auf.
Fünfunddreißig dieser Meldungen wurden zu Sätzen, mit denen ein Mensch etwas anfangen kann, wie "Wir konnten deine Organisationen nicht laden. Versuch es gleich noch einmal." Klare Sprache überall dort, wo ein Mensch mitliest. "Invalid member id" und ähnliche Fehler sagen jetzt, was schiefgelaufen ist, statt Variablennamen zu nennen. Die Konsolenzeilen, mit denen sie früher verwechselt wurden, bleiben unberührt, denn die sind wirklich für uns. Dasselbe gilt für die API-Shape-Validierung, die du zurückbekommst, wenn du uns per Code aufrufst, sowie für die maschinenlesbaren Codes, anhand derer das Dashboard verzweigt.
E-Mails wurden genauso überarbeitet. Eine Einladung, die eine unbekannte Person bittet, "einer Organisation" beizutreten, landet direkt im Papierkorb. Deshalb sind die von dir gewählten Namen wieder da: der Account, der Key, die Organisation und wer dich eingeladen hat. Freitext, den ein Kunde eingetippt hat, bleibt weiterhin aus jeder E-Mail draußen, die wir versenden.
Unter der Haube
Browser verlor pro Rendering-Session einen File-Handle, und es lag nicht an unserem Code. Eine Upstream-Dependency schließt einen ihrer zwei Log-Handles, bricht dann vorzeitig ab und überspringt den zweiten, allerdings nur, wenn der Aufrufer ein eigenes Profilverzeichnis übergibt. Wir übergeben bei jedem Start eines, wodurch das Leak sowohl garantiert als auch permanent war.
Der Patch wrappt diese einzelne Methode, anstatt die Dependency zu forken. Er führt zuerst das Original aus und greift nur ein, wenn der Handle noch offen ist. Sobald Upstream diese Zeile vor das Return verschiebt, wird unser Patch stillschweigend zum No-op. Die Tests reproduzieren das Leak, bevor der Patch installiert wird. So dokumentiert die Datei genau, wogegen sie absichert, statt nur zu behaupten, dass alles in Ordnung ist.
Der praktische Effekt: Langlebige Browser-Instanzen behalten ihre Kapazität, anstatt mit zunehmender Zahl an Sessions einzubrechen. Wenn du kontrollieren willst, wie diese Sessions auf der Leitung aussehen: browser profiles wurden parallel dazu ausgeliefert.
Beide oben genannten Fixes hatten denselben Ursprung. Etwas bestand einen Check, der gar nicht der entscheidende war: eine grüne Test-Suite, während in jeder Periode eine Stunde fehlte; ein Prozess, der sich einsatzbereit meldete, obwohl ihm genau die eine Ressource ausgegangen war, die er brauchte. Grün ist leicht zu erreichen. Die schwierigere Frage ist, was deine Messinstrumente sehen müssten, bevor sie auf Rot springen, und ob sie es überhaupt sehen können.