要求一份必须通过测验的报告,能把「我扫了一眼 diff」变成经核实的理解——成品不会让你觉得完成了,直到你真的理解为止。
我想在合并前确保理解这次变更中发生的一切。给我一份关于导出功能 diff 的 HTML 报告——背景、直觉、做了什么——底部附一个我必须通过的测验。
一个 14 文件的 diff,为审阅线程添加服务端片段导出。阅读下方三个章节,然后通过测验。若不能,你还没准备好合并——这正是要点。
一图胜 14 个文件:导出请求现在与之前的路径对比。
此变更前,「导出片段」意味着浏览器用 MediaRecorder 在客户端拼接帧并上传结果——慢、锁定标签页,且在 Safari 上不可用。现在客户端只请求导出;新 worker 从原始媒体在服务端渲染,客户端轮询任务直到出现签名下载 URL。
扫 diff 看不出的部分。每一处都是刻意的——理由如下。
media/originals/,从不使用 720p 审阅代理。因此导出片段可能比审阅者画批注时看到的更清晰。locked_until = now() + 10min 认领任务行。若 worker 渲染中途崩溃,不会触发重试;锁只是过期,下一个空闲 worker 从头接手该任务。GET /api/exports/:id 返回的签名 S3 URL 有效期 24 小时,但底层对象在 7 天生命周期规则触发前不会删除。再次请求端点可生成新 URL,无需重新渲染。工作区范围的签名 URL 鉴权。GET /api/exports/:id 自身不做权限检查——它复用已守护每条媒体路由的 requireWorkspaceMember 中间件。若该中间件的会话处理发生变化(有一张关于访客审阅者会话的开放工单 BL-2214),导出下载会随之改变。此 diff 中没有任何内容会标记这一点。
6/6 — 你能向被 paging 的人解释这次变更。下方为标准清单。
你答错了以下问题。缺口直接对应报告内容: