E2E: auth 系シナリオ (whoami / auto-refresh) が実行順序・環境依存で間欠的に 401 になる

[miya0001]

概要

E2E の auth 系シナリオ (auth.feature) が間欠的に 401 で落ちる。落ちるのは常に以下の組み合わせ (全部または一部):

1. Display user info when logged in (geonic whoami → Authentication failed)
2. Whoami with JSON format (同上)
3. Automatic token refresh on 401 (geonic entities list → Authentication failed)

いずれも Given I am logged in (tenant-admin の /auth/login 直 fetch) は成功した直後に、CLI サブプロセスの認証付きリクエストが 401 になる。

証拠 (2026-07-14 ローカル調査)

同一コード・同一マシンでの実行結果:

時刻	ブランチ	実行方法	結果
14:53	fix-138 (本体最新)	npm run test:e2e	141 全パス
14:56	fix-138	npm run test:e2e	141 全パス
15:04	fix-139 (本体 pinned 旧)	npm run test:e2e	1 failed (whoami)
15:08-12	fix-139	npx cucumber-js auth.feature:37 ×3	全パス
15:2x	fix-139 (rebase 後、本体最新)	npm run test:e2e	3 failed
15:3x	fix-138 (変更なし)	npm run test:e2e	3 failed (同一シナリオ)
15:4x	fix-139	npx cucumber-js tests/e2e/features/auth.feature (パス引数あり・全141実行)	141 全パス
15:4x	fix-139	npm run test:e2e	3 failed
15:5x	fix-139	npx cucumber-js (引数なし)	3 failed

観察できたパターン:

• パス引数付き実行 (シナリオ実行順が変わる) では落ちたことがない。引数なし実行は同時期に高確率で落ちる → 実行順序依存の状態汚染が濃厚
• CLI 変更の有無と無関係 (変更ゼロの base ブランチで再現)
• 本体のバージョン (pinned 326b12aa / 最新 53e27682) とも無関係に発生
• マシン負荷・時間帯で発生率が変わる。同一invocationでも 14時台は 2連続パス、15時台は連続失敗

CI への影響

週次互換性チェック 2026-07-13 の失敗 (run) はこの flake が原因とみられる (retry 3 回とも whoami 401)。#140 の調査により、当該 run は lockfile バグで旧 pinned 本体をテストしていたことが判明しており (= 7/6 の成功 run と同一コード)、コード互換性の問題ではありえない。

調査の手がかり

• 落ちる 3 シナリオは全部 tenant-admin ログイン + 認証付きリクエスト (or リフレッシュフロー)。super admin 系は落ちない
• loginAttempts コレクションは preserved (Before フックで baseline 復元) だが、サーバー内のインメモリなレート制限/ロックアウト状態はシナリオ間でリセットされない可能性
• CLI のプロアクティブトークンリフレッシュ (fix: token+apiKey 共存時のセッション切れを修正 #98) が絡む可能性 (Automatic token refresh シナリオも落ちる)
• ローカル調査時、別プロセスの geonicdb local-server が port 3000 を占有しており、E2E サーバーは 3001 にフォールバックしていた時間帯がある (直接の因果は未確認)

期待する対応

1. 根本原因の特定 (シナリオ実行順を固定/シャッフルして再現条件を絞る、サーバー側 401 の理由をログで捕捉する等)
2. 落ちる原因となる状態汚染の解消、または Before フックでのサーバー側インメモリ状態リセット
3. それまでの暫定として、当該シナリオの安定化 (リトライではなく原因ベースで)

[miya0001]

根本原因 特定 (2026-07-14)

サーバーの logout 仕様が原因。 AuthService.logout() は invalidatedBefore = floor(now/1000) + 1 でユーザーの全トークンを無効化するため、logout と同一壁時計秒内に正規再ログインで発行された新トークン (iat が同じ秒) も無効化窓に入る。E2E はシナリオを数百 ms で回すので、logout 系シナリオの直後の Given I am logged in → 認証付きコマンドが高頻度で 401 になる。

実測 (スタンドアロン再現スクリプト):

• logout → 即再ログイン → /me: 10/10 失敗
• logout → 1.1 秒待機 → 再ログイン → /me: 0/10 失敗

standalone モードでは無効化レコードがインメモリ保持のため Before フックの DB クリーンアップでは除去できず、実行順序・マシン速度で発現が揺らぐ (= 観測した順序・環境依存性の正体)。cucumber retry が同一秒内に収まると 3 連敗するのも整合。

• 本体側 issue: geolonia/geonicdb#1351 (logout 直後の正規新トークンまで無効化される設計課題)
• CLI 側恒久対策: PR test: E2E ログインでトークン実効性を検証し logout 無効化窓の flake を解消 (closes #142) #143 (loginAs で /me 検証 + 窓を跨ぐリトライ)