Points clés
L'utilisation prend désormais en compte chaque heure couverte par votre période de facturation, de sorte que le total des crédits sur votre page Usage & Limits couvre la période dès sa première seconde. Les organisations bénéficient du suivi complet qui leur manquait la semaine dernière : la personne que vous ajoutez en est informée, le propriétaire dont le forfait paie également, et le sélecteur de rôle indique enfin ce qu'un rôle autorise. Nous avons aussi passé en revue le Dashboard pour réécrire les messages qui avaient été rédigés pour nous plutôt que pour vous.
Nouveautés
Chaque heure de votre période compte
Votre période de facturation commence à la seconde exacte de votre inscription. L'utilisation est mesurée par intervalles fixes. Ces deux éléments ne s'alignent presque jamais, donc le calcul qui fait correspondre l'un à l'autre doit être rigoureusement exact aux extrémités.
C'est désormais le cas. Une période est découpée en intervalles entiers à la résolution la plus fine encore disponible pour chaque partie, sans division approximative ni double comptage. Les trois emplacements qui lisent l'utilisation partagent une implémentation unique, ce qui constitue le véritable correctif. Avoir trois copies du même calcul est la raison pour laquelle l'une d'elles finit par être fausse.
Ce que vous remarquerez : chaque chiffre sur Usage & Limits affiche une valeur légèrement supérieure à celle de la semaine dernière. Même trafic, décompte plus complet. Ce changement ne fait dépasser la limite de forfait à personne. Le même calcul régule votre quota, cela avait donc de l'importance dans les deux sens.
Personne ne rejoint une organisation en silence
Les organisations sont arrivées la semaine dernière et vous pouviez ajouter un collègue, lui attribuer un rôle et lui permettre d'utiliser les clés payées par l'entreprise. Ce que vous ne pouviez pas faire, c'était le prévenir. L'indication sous le formulaire vous invitait à le faire vous-même.
Deux e-mails sont désormais envoyés. La personne ajoutée en reçoit un précisant le nom de l'organisation, qui l'a ajoutée, les permissions de son rôle et la procédure pour la quitter si elle ne s'y attendait pas. Le propriétaire en reçoit un dès que quelqu'un rejoint l'organisation, car les clés de l'organisation sont facturées sur son forfait et le fait qu'une personne de plus utilise ses crédits le concerne directement, ce n'est pas une simple politesse. Aucun e-mail n'est envoyé à la personne qui a cliqué sur le bouton. Vous n'avez pas besoin d'un accusé de réception pour votre propre action.
La notification destinée au propriétaire se déclenche dans les deux cas : un ajout direct, ou une invitation acceptée lors de la première connexion, cas où aucun acteur n'intervient puisque la personne s'est connectée d'elle-même.
Les rôles sont également explicités. Une ligne sous le sélecteur s'adapte selon votre choix, et la colonne Role affiche une info-bulle détaillée pour les trois options, y compris le propriétaire. Devoir choisir entre "Member" et "Admin" sans savoir ce que chacun permet conduit souvent à attribuer le rôle d'administrateur par défaut.
Une seule étape pour ajouter un collègue
Saisissez une adresse e-mail, cliquez sur Add. S'il utilise déjà FourA, il rejoint l'organisation immédiatement. Si ce n'est pas le cas, nous lui envoyons une invitation par e-mail et il y accède dès sa connexion. Même bouton, même confirmation, même résultat dans les deux cas, et la page décrit ces deux issues en une seule phrase au lieu d'indiquer celle qui s'applique à l'adresse saisie.
Cette deuxième boîte de dialogue a disparu, tout comme la réponse qui vous indiquait si une adresse possédait déjà un compte ici. Savoir si une adresse email arbitraire est enregistrée chez nous n'est pas une question à laquelle nous répondons.
Le Dashboard a cessé d'écrire dans le journal
« Failed to fetch organizations » est une ligne qui nous est destinée. Elle s'affichait sous vos yeux.
Trente-cinq de ces messages sont devenus des phrases exploitables pour un humain, comme « Nous n'avons pas pu charger vos organisations. Réessayez dans un instant. » Des formulations directes partout où un humain lit. « Invalid member id » et ses variantes expliquent désormais ce qui a échoué au lieu de nommer une variable. Les lignes de console avec lesquelles ils étaient auparavant confondus restent inchangées, car elles nous sont réellement destinées. Il en va de même pour la validation du format de l'API renvoyée lorsque vous nous appelez via du code, ainsi que pour les codes lisibles par machine sur lesquels le Dashboard se base.
Les emails ont reçu le même traitement. Une invitation demandant à un inconnu de rejoindre « une organisation » finit directement à la corbeille, donc les noms que vous avez choisis sont de retour : le compte, la clé, l'organisation, la personne qui vous a invité. Le texte libre saisi par un client reste exclu de chaque email que nous envoyons.
Sous le capot
Browser subissait une fuite d'un descripteur de fichier par session de rendu, et notre code n'en était pas la cause. Une dépendance en amont ferme l'un de ses deux descripteurs de journal, puis effectue un retour anticipé et ignore le second, mais seulement lorsque l'appelant fournit son propre répertoire de profil. Nous en fournissons un à chaque lancement, ce qui rendait la fuite à la fois systématique et permanente.
Le correctif encapsule cette unique méthode plutôt que de forker la dépendance. Il exécute d'abord l'original et n'intervient que si le descripteur est toujours ouvert, de sorte que le jour où le projet en amont déplace cette ligne avant le retour, notre correctif devient silencieusement inopérant. Les tests reproduisent la fuite avant l'application du correctif, afin que le fichier explicite ce contre quoi il se protège au lieu d'affirmer simplement que tout va bien.
Effet pratique : les instances de Browser à longue durée de vie maintiennent leur capacité au lieu de s'épuiser au fil des sessions. Si vous souhaitez contrôler l'aspect de ces sessions sur le réseau, les profils de navigateur ont été livrés en même temps.
Les deux correctifs ci-dessus partent du même constat. Quelque chose a réussi un test qui n'était pas le test pertinent : une suite de tests au vert alors qu'une heure manquait à chaque période, un processus prêt à l'emploi alors qu'il avait épuisé la seule ressource indispensable. Obtenir du vert est facile. La question la plus difficile est de savoir ce que vos instruments devraient constater avant de passer au rouge, et s'ils sont capables de le détecter.