Главное
Использование теперь учитывает каждый час расчетного периода, поэтому сумма кредитов на странице Usage & Limits охватывает период с первой секунды. Организации получили доработки, которых не хватало на прошлой неделе: добавленный пользователь получает уведомление, владелец платящего тарифа тоже, а выбор роли теперь поясняет доступные права. Также мы прошлись по Dashboard и переписали сообщения, которые были понятны только нам, а не вам.
Что нового
Учитывается каждый час расчетного периода
Ваш расчетный период начинается в секунду регистрации. Использование измеряется фиксированными интервалами. Эти два значения почти никогда не совпадают, поэтому сопоставление на границах должно быть точным.
Теперь так и есть. Период разбивается на полные интервалы с максимальным доступным разрешением для каждого отрезка: ничего не делится и не учитывается дважды. Все три места, читающие использование, используют единую реализацию. Это и есть главное исправление. Три копии одной и той же логики неизбежно приводят к ошибкам в одной из них.
Что изменилось: все числа на странице Usage & Limits стали чуть выше, чем на прошлой неделе. Тот же трафик, более полный учет. Из-за этого изменения никто не выйдет за лимиты тарифа. Та же логика управляет лимитами квот, поэтому точность важна в обе стороны.
Никаких скрытых добавлений в организации
Организации появились на прошлой неделе, позволив добавлять коллег, назначать им роли и давать доступ к ключам компании. Но уведомить их система не могла. Подсказка под формой предлагала сделать это вручную.
Теперь отправляются два письма. Добавленный пользователь получает письмо с названием организации, именем пригласившего, описанием прав роли и ссылкой на выход, если это произошло по ошибке. Владелец получает письмо при вступлении нового участника, так как ключи организации расходуют баланс его тарифа, и появление нового пользователя напрямую касается владельца. Письма не отправляются тому, кто нажал кнопку: подтверждение собственного действия не требуется.
Уведомление владельцу срабатывает в обоих сценариях: при прямом добавлении и при принятии приглашения при первом входе, когда действие инициировано самим пользователем.
Роли теперь также снабжены пояснениями. Строка под селектором меняется при выборе, а в столбце Role появилась подсказка по всем трем ролям, включая владельца. Выбор между "Member" и "Admin" вслепую часто приводил к тому, что права администратора раздавали по умолчанию.
Добавление коллеги в один шаг
Введите адрес электронной почты и нажмите Add. Если пользователь уже зарегистрирован в FourA, он присоединяется сразу. Если нет, мы отправляем приглашение на почту, и он подключается в момент входа. Одна кнопка, одно подтверждение и одинаковый результат в обоих случаях, а страница описывает оба варианта одним предложением вместо разделения логики под каждый введенный адрес.
Второй диалог удален, как и ответ, который раньше сообщал, зарегистрирован ли уже такой адрес. Зарегистрирован ли у нас произвольный email, мы больше не отвечаем.
Dashboard перестал писать в лог
Строка "Failed to fetch organizations" предназначена для нас. Но она отображалась пользователям.
Тридцать пять таких сообщений стали понятными фразами с четким действием, например: "Не удалось загрузить ваши организации. Повторите попытку чуть позже." Сокращения везде, где читает человек. Сообщение "Invalid member id" и похожие теперь объясняют суть проблемы вместо вывода имени переменной. Строки консоли, с которыми их раньше путали, остались без изменений, поскольку они действительно нужны нам. Это же касается валидации структуры API при вызовах из кода и машиночитаемых кодов, на которых ветвится Dashboard.
Письма прошли такую же переработку. Приглашение присоединиться к "an organization", отправленное незнакомому человеку, обычно сразу летит в корзину. Поэтому понятные названия возвращены: аккаунт, ключ, организация, имя пригласившего. Произвольный текст, введенный клиентом, по-прежнему исключен из всех отправляемых нами писем.
Под капотом
Browser терял по одному файловому дескриптору на каждую сессию рендеринга, причем не из-за нашего кода. Зависимость выше по цепочке закрывает один из двух дескрипторов логов, а затем выполняет ранний return и пропускает второй, но только если вызывающая сторона передает собственный каталог профиля. Мы передаем его при каждом запуске, из-за чего утечка была гарантированной и постоянной.
Патч оборачивает этот конкретный метод вместо создания форка зависимости. Он сначала запускает оригинальный метод и вмешивается, только если дескриптор все еще открыт. Поэтому в день, когда upstream перенесет эту строку выше return, наш патч просто перестанет выполнять какие-либо действия. Тесты воспроизводят утечку до применения патча, поэтому файл явно фиксирует проблему, от которой защищает, а не просто утверждает, что все в порядке.
Практический результат: долгоживущие экземпляры Browser сохраняют свою емкость, а не деградируют по мере накопления сессий. Если вам нужно управлять тем, как эти сессии выглядят в сети, вместе с этим релизом вышли browser profiles.
Оба описанных исправления начались с одной и той же проблемы. Что-то прошло проверку, которая на самом деле ничего не гарантировала: зеленый набор тестов при пропаже одного часа из каждого периода, процесс, рапортующий о готовности к работе, когда у него закончился единственный необходимый ресурс. Зеленый статус получить легко. Гораздо сложнее понять, что именно должны зафиксировать ваши инструменты мониторинга, чтобы загорелся красный, и способны ли они вообще это увидеть.