判定任务 · sampling-url.crs.tongsou.com

为什么这张表必须有超时

DEV-sampler.md §七 · 这是回调可靠性的一部分，不是优化

调度器有两道兜底：lease 超时、domain_judgement_task 超时。采样器自己这道不能缺。没有它会这样：

step步骤	what happens发生什么
1	采样任务卡死（render 持续 429、goroutine 挂了、样本页全超时）
2	采样器不回调
3	调度器的判定任务超时兜住了，它会重投
4	但 `sampler:judgement_task` 永远躺着
5	该域名在采样器视角里是「处理中」，不是 `unknown`
6	★ 它不会出现在待定池里

⚠️ 待定池只能看见「采样器知道自己失败了」的那批，看不见「卡住了自己不知道」的那批 —— 而后者最需要外部介入。这是整个待定池机制里最容易漏的一个洞。

⚠️ 本机制与调度器的 domain_judgement_task 超时两层不冲突：调度器那道只兜「采样器完全没回调」（进程挂了），本服务这道兜「任务卡住但进程还活着」。

扫 sampler:judgement_task，first_submitted_at 超时的

step步骤	action动作
1	写 `sampler:domain_rule`：`verdict = unknown`，`undetermined_reason = judgement_timeout`
2	`POST scheduling-url/v1/rules`
3	删除 `judgement_task`

⚠️ unknown 必须回调，不能静默不回，含任务超时的情况。否则该域名会永远卡在调度器的 domain_judgement_task 里。

⚠️ 回收时照常写 domain_rule。不写表，同一域名每被链接一次就重新采样，真烧 3~5 次渲染。

sampler:judgement_task:{task_id} · 唯一写入方采样器

task_id任务标识	domain域名	reason提交原因	first_submitted_at首次提交时间	page_sample_count已采样页数	elapsed已用时长	state状态
t-9f31a04c	forum.example.tw	new	2026-08-15T07:41:12Z	3	7 分钟	采样中
t-2b8e77d1	wiki.example.jp	new	2026-08-15T07:38:44Z	5	9 分钟	判定中
t-6c04ba39	news.example.hk	recheck	2026-08-15T07:20:03Z	4	28 分钟	采样中
t-51da0e88	slow.example.com	new	2026-08-15T05:12:39Z	1	2 小时 35 分	接近超时
t-73fbc215	stuck.example.net	manual	2026-08-15T03:58:07Z	0	3 小时 49 分	下轮回收

⚠️ 最后一行 page_sample_count = 0 且已用 3 小时 49 分：典型的「卡住了自己不知道」。下一轮扫描会把它改判 unknown / judgement_timeout 并推进待定池 —— 这正是本机制存在的理由。

⚠️ reason 取值只有 new / recheck / manual 三个，定义在 CONTRACT.md §四。不得新增第四个取值，新增要走三方确认。

⚠️ 本表完整字段以 keyspace/schema.go 为准。文档明确提到的只有 first_submitted_at 与任务状态本身，本页不替 schema 定名 —— 表清单从代码生成，代码是唯一来源。

DEV-sampler.md §三 · 样本代表性直接决定判定准确率

priority优先级	source来源	note说明
1	sitemap.xml	`should_render = false` 取，随机选 3~5 条内容页
2	首页渲染后提链接	同域链接，优先路径较深的
3	首页本身	兜底，标 `page_sample_count = 1`，置信度低

⚠️ 只取首页会误判 —— 很多站首页是 SSR（为了 SEO 和首屏），内容页才是 CSR。

⚠️ 排除登录页 / 注册页（内容极少，必然误判为 CSR）与 404 / 错误页。