|
|
bc0fce4edd
|
fix: 爬虫页队列数被查询 LIMIT 截断（显示 199，实际 1620）
队列数字原本取 len(查询结果)，而 ListActive 带 LIMIT 200：
1 个执行中 + 199 个排队刚好凑满，页面就永远显示 199，
看起来像「队列被卡住了、只有这么点任务」。
- 数字改用 SELECT count(*) GROUP BY status，不受 LIMIT 影响
- 表格仍只列前 50 个（渲染上千行会拖慢页面），
并在标题下注明「共 N 个，下面只列前 50 个」
- 渲染测试新增一条：截断时必须出现提示文案
|
2026-10-27 15:10:53 +08:00 |
|
|
|
e930ac41c8
|
feat: 爬虫页取代抓取任务/入库任务两页，抓取改全量+覆盖率跳过
一、后台只留一个「爬虫」页（/admin/spider）
抓取与入库本就是同一条流水线的上下游，分两页看谁都看不全。
新页三块：状态条（在线/卡住 + 队列数 + 待入库数）、正在抓（含进度与心跳）、
最近入库结果（品牌/场次/结果/说明）。只读，取消与重试一并下线。
二、抓取一律全量
删除品牌页的场次上限下拉与 hidden maxShows=3，入队固定 0（全量）。
crawl_tasks.max_shows 列保留，历史任务照常显示。
三、跳过判定改覆盖率
- brand_runways 增加 expected_images（spider 上报的应有张数）
- /shows/covered 返回 images + expected
- 实际张数 >= 应有 - 5 才跳过；expected=0 时回落 10 张阈值
- 实体已存在时不再直接跳过：按 key 比对把缺的图补进库（repaired）
否则「判定不完整→重爬→后端跳过」会形成死循环，带宽白花、缺图永远补不上
四、租约 900→300 秒，且心跳算存活
只看 locked_at 会把跑了几小时的全量抓取误判成卡死；
加上 progress_at 后，真卡住 5 分钟才回收。
|
2026-10-25 23:59:54 +08:00 |
|
|
|
51e3d13383
|
feat: 抓取进度可见 + 已入库秀预检（避免重复下载）
一、防重复下载
图片 key 是内容 sha1，不下载无法判断是否已存在；又没存 source_url，
于是每次重爬都把几百张已下过的图再下一遍（线上实测 Celine 62 分钟、0 新增）。
新增 GET /admin/internal/shows/covered?brand_uid=，按 (年份,季节,类型)
聚合已入库图片数，供 spider 抓前整场跳过。
二、进度可见
一次抓取可能跑几十分钟，此前只有 running/done，看不出「在干什么」，
也分不清「慢」和「卡死」。
- crawl_tasks 增加 progress_done/total/text/at
- POST /admin/internal/crawl/tasks/:id/progress（spider 每场 + 每批图片上报）
- GET /admin/crawl/live（页面 4 秒轮询，局部刷新状态/进度/已提交）
- progress_at 超过 10 分钟没更新标黄「可能卡住」
- 渲染测试守住进度列与轮询锚点
|
2026-10-25 21:22:56 +08:00 |
|
|
|
64b264ee73
|
feat: 品牌抓取历史（brand_crawl_logs）+ 品牌页展示
crawl_tasks 每品牌只有一行（uq_crawl_tasks_brand），入队/完成都是覆盖，
答不了「什么时候爬过、爬了几次、哪次没抓到」。故新增 append-only 历史表：
- 在 Report 的同一事务里写一条：品牌 / 任务 / 状态 / 第几次尝试 /
场次上限 / 实际上报场次 / 错误 / 执行者 / 领取与回报时间
- 写入后只保留该品牌最近 30 条（CrawlLogKeepPerBrand），
历史用于排障而非归档，避免无限增长
- 品牌详情页新增「抓取历史」区块（结果 / 明细 / 耗时 / 执行者），
与「更新记录」上下相邻，构成「抓取一次 → 每场入库结果」的完整链路
量级：每品牌每次抓取 1 行、约 200B（含索引）；全站跑一遍 23237 行 ≈ 4.6MB。
|
2026-10-25 11:37:43 +08:00 |
|
|
|
c8a70760cc
|
feat: 入库结果落库 + 品牌详情展示更新记录
背景：任务只有 status=done，分不清「新建」「已存在跳过」「已删除跳过」，
品牌更新历史只能在进程日志里翻，日志一滚就没了。
- ingest_jobs 新增 outcome / note / brand_id（迁移 2026-10-25-01）
outcome 记结果类型，note 记人话细节（新建 N 张图 / 已存在(status=published)）
- 提交任务时解出 brand_id 落库，品牌详情页按 (brand_id, id DESC) 直接查
- 处理时优先用 job.brand_id，payload 里的 hashid 只作老任务兜底：
避免「别的实例盐不同 → 解出错品牌 → 整场 brand not found」再发生
- 品牌编辑页新增「更新记录」区块：时间 / 场次 / 结果 / 明细（含失败原因与尝试次数）
- 测试：fake 仓储补齐新接口，capture 仓储记录 outcome 供断言
|
2026-10-25 11:06:16 +08:00 |
|
|
|
151e09ab30
|
feat: 抓取任务队列 + 媒体机直传 + 向量回填
crawl（品牌抓取任务队列）
- /admin/internal/crawl/tasks 领取 / :id/result 回报，spider 可常驻拉任务
- 后台品牌列表支持「加入抓取队列」，队列页可看状态与重试
- 租约超时的 running 自动回收为 queued，避免 worker 崩溃后任务卡死
media（媒体机直传）
- ingest 载荷新增 main_key/detail_keys/main_size/detail_sizes：
有 key 就直接落库，跳过下载与上传；与 URL 形态可逐图混用
- 细节图按 Details/DetailKeys 两者较长者遍历（只给 key 时不再丢图）
- 媒体机上传的 key 不进失败回滚清单（内容寻址、可能与他人共享）
- /admin/internal/upload-url 签发 S4 PUT 预签名（spider 不持有 AK/SK）
embeddings（向量回填）
- GET /admin/internal/embeddings/pending 派发缺向量的图（含可直接下载的 url）
- POST /admin/internal/embeddings 回写向量并重算近邻；失败项计入
image_embedding_failures，连续失败到上限后退出队列（坏图不占位）
- 近邻重算改为异步串行：同步会让 100 张的批次 POST 超时（实测 >60s）
- 新增 key 分支单测：混用 key/url、细节图只给 key、字节数、回滚清单、向量占位
|
2026-10-25 00:37:13 +08:00 |
|
|
|
1de1ec46a6
|
update
|
2026-10-18 17:42:10 +08:00 |
|
|
|
1b06bd5bda
|
update
|
2026-09-30 11:58:32 +08:00 |
|
|
|
361ffc01af
|
update
|
2026-09-29 19:59:30 +08:00 |
|
|
|
d15d2a4701
|
update
|
2026-09-28 10:52:50 +08:00 |
|
|
|
42f6316125
|
update
|
2026-09-25 11:31:52 +08:00 |
|
|
|
76626b8372
|
refactor(publish): 审核侧切到正式表，通过即改状态不再晋升
|
2026-09-23 11:09:12 +08:00 |
|
|
|
c3a6baa419
|
update
|
2026-09-22 21:40:04 +08:00 |
|
