Puntos clave
El uso ahora contabiliza cada hora que abarca tu periodo de facturación, por lo que el total de créditos en tu página de Usage & Limits cubre el periodo desde su primer segundo. Las organizaciones recibieron el seguimiento que les faltaba la semana pasada: la persona que agregas recibe una notificación, al igual que el propietario cuyo plan paga, y el selector de roles finalmente explica qué puede hacer cada rol. Además, revisamos el Dashboard y reescribimos los mensajes que estaban redactados pensando en nosotros en lugar de en ti.
Novedades
Cada hora de tu periodo cuenta
Tu periodo de facturación comienza en el segundo exacto en que te registraste. El uso se mide en bloques fijos. Esas dos cosas casi nunca coinciden, por lo que la aritmética que mapea una sobre la otra debe ser exacta en los límites.
Ahora lo es. El periodo se divide en bloques completos con la resolución más precisa aún disponible para cada parte, sin divisiones intermedias ni recuentos duplicados. Los tres lugares que leen el uso comparten una única implementación, que es la solución real. Mantener tres copias del mismo cálculo aritmético es la razón por la que una de ellas termina fallando.
Lo que notarás: cada cifra en Usage & Limits se muestra ligeramente más alta que la semana pasada. Mismo tráfico, recuento más completo. Nadie supera el límite de su plan debido a este cambio. El mismo cálculo regula tu cuota, por lo que era importante en ambas direcciones.
Nadie se une a una organización en silencio
Las organizaciones llegaron la semana pasada y podías agregar a un colega, asignarle un rol y permitirle usar las keys que paga la empresa. Lo que no podías hacer era avisarle. El texto de ayuda debajo del formulario indicaba que debías hacerlo tú mismo.
Ahora hay dos correos. La persona agregada recibe uno donde se indica la organización, quién la agregó, qué puede hacer su rol y desde dónde salir si no esperaba recibir esto. El propietario recibe uno cuando alguien se une, porque las keys de la organización se facturan contra su plan y una persona más consumiendo sus créditos es un asunto relevante, no una simple cortesía. Ninguno de los dos correos se envía a quien presionó el botón. No necesitas un comprobante de tu propia acción.
La notificación del propietario se activa en ambos casos: cuando se agrega a alguien directamente y cuando se acepta una invitación en el primer inicio de sesión, donde no hay un actor explícito porque la persona ingresó por su cuenta.
Los roles también se explican por sí mismos. Una línea debajo del selector cambia a medida que eliges, y la columna Role incluye un tooltip que cubre las tres opciones, incluida la de propietario. Elegir entre "Member" y "Admin" sin saber qué puede hacer cada uno es la razón por la que la gente otorga permisos de administrador por defecto.
Un solo paso para agregar a un colega
Escribe una dirección de correo, presiona Add. Si ya usa FourA, se une de inmediato. Si no, le enviamos una invitación por correo y entra en cuanto inicia sesión. Mismo botón, misma confirmación, misma respuesta en ambos casos, y la página describe ambos resultados en una sola frase en lugar de especificar cuál aplica a la dirección que escribiste.
Ese segundo cuadro de diálogo desapareció, y también la respuesta que solía decirte si una dirección ya tenía una cuenta aquí. Que un correo electrónico arbitrario esté registrado con nosotros no es una pregunta que respondamos.
El Dashboard dejó de escribir en el log
"Failed to fetch organizations" es una línea para nosotros. Aparecía frente a ti.
Treinta y cinco de esos mensajes se convirtieron en frases sobre las que una persona puede actuar, como "No pudimos cargar tus organizaciones. Inténtalo de nuevo en un momento". Contracciones en cualquier lugar donde lea un humano. "Invalid member id" y sus variantes ahora explican qué salió mal en lugar de nombrar una variable. Las líneas de consola con las que solían confundirse permanecen intactas, porque esas realmente son para nosotros. Lo mismo ocurre con la validación de estructura de API que recibes cuando nos llamas desde el código, y con los códigos legibles por máquina sobre los que se bifurca el Dashboard.
Los correos electrónicos recibieron el mismo tratamiento. Una invitación que pide a un desconocido unirse a "una organización" es el correo que la gente descarta, así que los nombres de las cosas que elegiste están de vuelta: la cuenta, la clave, la organización, quien te invitó. El texto libre que escribe un cliente sigue quedando fuera de cada correo que enviamos.
Bajo el capó
Browser estaba filtrando un descriptor de archivo por sesión de renderizado, y no era nuestro código el que lo hacía. Una dependencia upstream cierra uno de sus dos descriptores de log, luego retorna antes de tiempo y omite el segundo, pero solo cuando quien llama suministra su propio directorio de perfil. Nosotros suministramos uno en cada inicio, lo que hizo que la fuga fuera tanto garantizada como permanente.
El parche envuelve ese único método en lugar de bifurcar la dependencia. Ejecuta el original primero y solo actúa si el descriptor sigue abierto, por lo que el día en que upstream mueva esa línea antes del return, nuestro parche pasará a ser silenciosamente un no-op. Las pruebas reproducen la fuga antes de instalar el parche, por lo que el archivo declara aquello contra lo que se defiende en lugar de limitarse a afirmar que todo está bien.
Efecto práctico: las instancias de Browser de larga duración mantienen su capacidad en lugar de mermar a medida que se acumulan las sesiones. Si quieres controlar cómo se ven esas sesiones en la red, browser profiles se lanzó junto con esto.
Ambas correcciones anteriores comenzaron en el mismo lugar. Algo superó una validación que no era la que importaba: una suite de pruebas en verde mientras faltaba una hora en cada período, un proceso reportándose listo para operar cuando se había quedado sin el único recurso que necesitaba. Obtener verde es fácil. La pregunta más difícil es qué tendrían que ver tus instrumentos antes de ponerse en rojo, y si realmente pueden llegar a verlo.