ハイライト
請求期間に含まれるすべての時間が利用量としてカウントされるようになり、Usage & Limitsページのクレジット合計が期間の最初の1秒から正確に反映されるようになりました。組織機能には先週不足していたフォローアップを追加しました。追加されたユーザーやプランの支払いを行うオーナーへの通知が届くようになり、ロール選択UIで各権限の内容が確認可能になりました。また、Dashboard全体のメッセージを見直し、開発者目線ではなくユーザー目線の記述に書き換えました。
新機能・変更点
請求期間内のすべての時間をカウント
請求期間はサインアップした瞬間の秒単位から始まります。利用量は固定のバケット単位で計測されます。この2つはほぼ一致しないため、両者をマッピングする計算処理は境界値において厳密である必要があります。
今回の修正でそれが実現しました。請求期間は利用可能な最小解像度の完全なバケットに分割され、分割による誤差や重複カウントは発生しません。利用量を読み取る3つの箇所すべてで同一の実装を共有するようにしたことが根本的な修正点です。同じ計算処理を3箇所に重複して実装することが不整合の原因でした。
変更点として、Usage & Limitsの各数値が先週よりわずかに大きく表示されます。同一のトラフィック量でも、より完全な集計が行われるためです。この変更によってプラン制限を超過することはありません。同じ計算処理がクォータ制御にも適用されるため、双方の整合性が取れています。
組織への追加時の通知改善
先週リリースした組織機能では、同僚を追加してロールを割り当て、会社が支払うキーを利用させることができました。しかし、追加された本人への自動通知機能はありませんでした。フォーム下のヒントには、自分で連絡するよう記載されていました。
現在は2通のメールが送信されます。追加されたユーザーには組織名、追加者、ロールの権限内容、身に覚えがない場合の脱退手順が記載されたメールが届きます。オーナーには誰かが参加した際に通知されます。組織のキー利用はオーナーのプランに課金されるため、クレジットの消費者が増えることはオーナーにとって把握すべき重要事項であるためです。操作を実行した本人にはどちらのメールも送信されません。自分自身の操作に対する通知は不要です。
オーナーへの通知は、直接追加された場合と、初回サインイン時に招待を承諾した場合（追加操作者が介在せず本人が参加した場合）の双方で送信されます。
ロールの説明も強化しました。選択肢を選ぶとセレクター下の1行が切り替わり、Role列のツールチップにはオーナーを含む3つのロールすべての説明が表示されます。「Member」と「Admin」の違いが分からない状態では、安易に管理者権限を付与してしまう原因になります。
同僚の追加を1ステップに集約
メールアドレスを入力して「Add」を押すだけです。対象ユーザーがすでにFourAを利用していれば即座に参加します。未登録の場合は招待メールが送信され、サインインした瞬間に参加が完了します。同じボタン、同じ確認手順で処理され、ページ上でも入力したアドレスの登録状況に応じた分岐を1つの説明文に集約しました。
2つ目のダイアログは削除され、そのアドレスのアカウントが既に存在するかどうかを通知する応答もなくなりました。特定のメールアドレスが登録されているかどうかについて、お答えすることはありません。
Dashboardのログ出力の修正
「Failed to fetch organizations」は社内向けのログです。それがユーザー向け画面に表示されていました。
そのようなメッセージ35件を、「組織を読み込めませんでした。しばらくしてからもう一度お試しください。」といった、ユーザーが対処できる文章に変更しました。人間が読む場所には自然な表現を適用しています。「Invalid member id」やその類似メッセージは、変数名をそのまま出すのではなく、何が問題だったのかを明示するようにしました。混同されていたコンソールログは、社内向けであるため変更していません。コードからの呼び出し時に返されるAPIスキーマ検証や、Dashboardの条件分岐に使われる機械可読コードも同様です。
メール通知にも同様の修正を適用しました。見知らぬ人から「ある組織」への参加を促すような招待メールはゴミ箱行きになるため、アカウント、キー、組織、招待者の名前など、設定された名前が再び記載されるようになりました。ユーザーが入力した自由形式のテキストは、引き続き送信メールには一切含まれません。
内部構造
Browserがレンダリングセッションごとにファイルハンドルを1つリークしていましたが、原因は当社のコードではありませんでした。上流の依存関係が2つあるログハンドルのうち1つを閉じ、呼び出し元が独自のプロファイルディレクトリを指定した場合にのみ、2つ目をスキップして早期リターンしていました。当社では起動ごとにプロファイルを指定するため、リークが確実に、かつ永続的に発生していました。
このパッチは、依存関係をフォークするのではなく、その単一メソッドをラップしています。まず元の処理を実行し、ハンドルが開いたままの場合にのみ対処するため、上流でその行がリターン処理の前に移動された場合、パッチは何もしないコードになります。テストではパッチ適用前のリークを再現し、単に正常であることを検証するのではなく、何を防いでいるかを明示しています。
実際の影響として、長時間稼働するBrowserインスタンスは、セッションが蓄積してもパフォーマンスを落とさずにキャパシティを維持します。通信上でそれらのセッションがどのように見えるかを制御したい場合は、これと同時にリリースされたbrowser profilesを利用できます。
上記2つの修正は、どちらも同じ原因から始まりました。本質的でないチェックを通過してしまっていた点です。期間ごとに1時間が欠落しているのにテストスイートがグリーンになっていたり、必要なリソースが枯渇しているのにプロセスが稼働中と報告していたりしました。テストをグリーンにすること自体は容易です。より重要な問いは、監視システムが異常と判定するために何を検知する必要があるのか、そしてそれを実際に検知できる状態にあるのかということです。