28 行
1.9 KiB
Markdown
28 行
1.9 KiB
Markdown
# 初始证据：8 条会话回落失败
|
||
|
||
## 历史事实
|
||
|
||
- Residual 来源：`08-05-product-interaction-consistency` 父任务 PRD 的 Residual Register。
|
||
- 历史 runner：两份目标 spec 与其他三份回归同进程、`workers=1`、list reporter。
|
||
- 历史结果：R103 `4 passed / 7 failed`；global-search `3 passed / 1 failed`。
|
||
- 失败共同点：登录后发生完整 `page.goto`、reload 或第二次回到 portal，业务断言前进入 `/login`。
|
||
|
||
## 源码链路
|
||
|
||
1. 两份目标 spec 都 mock login/refresh/me；mock login 声明写 `has_session=1`。
|
||
2. 登录后的 access token 只在 React AuthProvider 内存中；完整页面重建不会保留它。
|
||
3. AuthProvider bootstrap 先检查 `document.cookie` 中的 `has_session=1`。无 hint 时不会请求 refresh，直接完成未认证状态。
|
||
4. 真实后端 login/refresh 同时设置 refresh cookie 与 session hint；refresh 还要求 device fingerprint 与 Origin/Host 合同。
|
||
5. 现有 `login-portal-ux` 用例在 bootstrap refresh 场景中显式用 init script 安装 session hint；这提示目标 fixture 的 cookie 是否真正进入 browser context 是首要待证假设，但尚不能据此下结论。
|
||
|
||
## 待验证假设
|
||
|
||
- H1（fixture）：`route.fulfill` 声明的 `set-cookie` 没有在目标 runner 中形成完整导航可见的 session hint，导致 AuthContext 不发 refresh。
|
||
- H2（fixture/order）：catch-all route、重复完整导航或 runner 顺序使 mock refresh/me 某次未命中。
|
||
- H3（product/integration）：真实 local refresh 因 device fingerprint、Origin/Host 或 rotation 行为失败，mock 症状只是碰巧相同。
|
||
- H4（mixed）：目标 fixture 缺 hint，同时真实集成路径也存在 Host/refresh 问题。
|
||
|
||
## 规划结论
|
||
|
||
不能从源码静态检查直接选择 H1。必须先原样复现，再通过 cookie/request ledger、session-hint 单变量控制和独立真实 session 对照定性。
|