Commit History
8 days ago
-
fix: recover bucket image persistence and finish history ZIPs before download
xiaolongmr2c2b631 -
fix: preserve cached history images before retrying renamed origin URLs
xiaolongmrbfe628f -
fix: restore portable history export and HF runtime configuration loading
xiaolongmr1904a10 -
fix: serve inline task images separately from lightweight polling JSON
xiaolongmree2d10d -
fix: move share evidence persistence off service locks and event loop
xiaolongmrb85cbbb -
fix: bound generated image persistence latency with inline fallback
xiaolongmr4bd0b4c -
fix: isolate chat attachment reads from the request event loop
xiaolongmr9730db1 -
fix: isolate generation health telemetry from persistent config locks
xiaolongmr8534c52
9 days ago
-
test: isolate model regressions and record HF acceptance evidence
xiaolongmr5a2d109 -
diagnostics: trace bounded image IO timeouts without request data
xiaolongmrdd9afb9 -
fix: serve newly persisted images from bounded hot caches
xiaolongmr3ab01a7 -
fix: handle disconnected uploads and bound HF image/config reads
xiaolongmr3241f40 -
fix: isolate HF slow-storage image metadata and avatar I/O
xiaolongmr7df78ec -
daochu baode format ziduan qudiao xiangmu ming, daoru jianrong jiu zhi
xiaolongmr导出包的 manifest.json 会随 zip 离开本机（用户分享、网盘备份）， format 字段里的项目名不该外泄。前端 LOCAL_HISTORY_FORMAT 与后端 HISTORY_FORMAT 统一换成中性的 image-history-package；导入端 （前端 detectHistoryPackage / isLocalHistoryPackage，后端 manifest 校验）同时接受旧值，已经导出的老包还能正常导回来。3adaf75 -
fix: prevent watchdog CPU spin and reduce navigation polling overhead
xiaolongmr0dc72aa -
tupian lishi neng daohuile, cankaotu yinyong jieguo tu bu chongfu cun zijie
xiaolongmr本地历史包导出时其实已经把参考图打进 references/，但导入端从未读过这个目录， 换机器后参考图全丢（缩略图空白、「拿这张参考图再生成」直接报读不到）。 - 导入分两趟：先落结果图（服务器探活，取不到的从 images/ 回填成本地 blob）， 再按引用回填参考图——引用了结果图的直接指回那份 blob / 地址，否则读 references/{turnId}-{index}.{ext}，两边都没有才记缺失并丢弃该项，避免留裂图。 清单里能跨会话用的服务端地址（sourceUrl / 老记录的 dataUrl）保留作兜底。 - 参考图就是某张生成结果图时只存指针：记录里写 resultRef，blobKey 直接复用 result: 前缀的键，本地 IndexedDB 不再复制一份 2MB 级字节；导出也跳过对应的 references/ 条目，manifest 增加 reused_reference_count。 - 草稿（composer draft）同理，只存 resultRef，恢复时按需去结果图取字节。 - 修 getLegacyReferenceImages 只按 dataUrl 非空过滤、把「只有 blobKey」的新格式 参考图整条丢弃的问题——这是导入后参考图变 0 张的直接原因。 - 孤儿 blob 回收白名单把共享键算进来，否则列表加载会把还在被引用的结果图删掉。 浏览器实测：保存后 blob 只有结果图一份；导出 zip 为 images/img-1.png + references/turn-1-1.png + manifest.json，reused=1； 清空后导入 referencesReused=1、参考图 storageKey 指向 result: 键且能读回字节； url-only 场景不为参考图另存字节；后端 pytest 失败集合与基线完全一致。64ea6ff -
kuaizhao shangchuan jiading shixian, shouci kuaizhao bu zai zuse qidong
xiaolongmr线上 07:36 那一轮启动卡了 33 分钟，本轮（08:10，85a872d0）已经能在 4 分钟内把 服务拉起来，日志里能看到四道超时全都按预期触发： cannot copy snapshot /app/persist/image_tasks.db: copy timed out after 90s skip salvage for image_tasks.db: copy already failed skip legacy image_tasks.json: copy timed out after 90s 但还剩两件事： 1. 快照上传路径没有时限。_snapshot_database 直接把整库 _copy_file 到 /app/persist，挂载写不动时快照线程会永久停住，之后再没有一份新快照。 线上 chat_room / chat_friends / users 的快照一直停在 20261027-174025 （users.db 每次重启都要 salvage，就是因为没有新快照可恢复）正是这个原因。 改为 _copy_file_bounded（默认 60s），失败后按库冷却 600s 再试，避免每 30 秒重撞挂住的挂载；单份快照超过 5s 会打一行耗时日志，便于判断挂载是否变慢。 2. start() 原来在 lifespan 里同步跑 snapshot_all(force=True)：那是往网络挂载 写整库，慢起来几十秒起步，等于把启动挂住；而且 _databases 为空时直接 return，连快照线程都不起（库是在存储初始化时逐个登记的，时机不确定）。 现在线程总是起，首份全量快照放到线程里跑，lifespan 立刻返回。 另外：_prepare_database 复制超时后记下这个库（_copy_failed），runtime_file 不再为它的 legacy JSON 再等一个 90s 超时——线上 image_tasks.json 那 90s 是纯白等。 测试：pytest test/ → 31 failed / 949 passed，与真基线逐条一致（NO_REGRESSION）。 注意必须带 test/ 参数，直接跑 pytest 在 Windows 上…29fa181 -
复制读不出来时不再进 salvage，避免同一个大对象上卡第二次
xiaolongmr真实卡点在 /app/persist/image_tasks.db（151MB 的 legacy 库文件，不是 json）：顺序复制 90 秒超时之后，_prepare_database 会去 salvage 它—— 先把整份复制到 sqlite-corrupt 做隔离（又是一次无超时的 151MB 读）， 再逐行 SELECT。同一个读不动的对象上再卡一次，这就是两轮重启都停在 「恢复完 chat_friends.db」之后的原因。 - 候选复制已经失败过（failed > 0）就直接跳过 salvage：它读的是同一个 文件，只会更慢。 - 真要 salvage 时，隔离复制受 20 秒上限约束，逐行恢复每 500 行检查一次 总时限（60 秒）。85a872d -
启动时不再复制 151MB 的 legacy image_tasks.json
xiaolongmr上一轮加的复制超时没救到这次启动：卡的是 runtime_file 里非 .db 分支的 _copy_file，它没有走超时包装。线上 image_tasks.json 有 151MB，而对应的 image_tasks.db 早就存在，这个 JSON 只是历史导入源，白复制一次就能把 启动拖死——两轮重启都停在「恢复完 chat_friends.db」之后，30 多分钟没有 任何输出。 - 复制 legacy JSON 之前先确保同名 SQLite 库已恢复；库在了就直接跳过。 - 真要复制时走 _copy_file_bounded，同样受单份 90 秒与启动总预算约束。ed5bcb6 -
给快照恢复加超时与总预算，避免挂载读挂死把启动卡成永久
xiaolongmr2026-10-28 那一轮：07:37:16 恢复完 chat_friends.db 之后 33 分钟没有任何 输出，容器一直停在 APP_STARTING。卡的位置是 image_tasks.db 的 151MB 快照，_copy_file 里的 open/read 在挂载上不返回也不报错，调用线程就永久 停在原地，而且没有任何超时能把它拉回来。 - 复制改到独立线程里等，单份超过 90 秒（CHATGPT2API_SQLITE_COPY_TIMEOUT） 就放弃这一份换下一个候选。超时后后台线程只写自己的临时文件，不会动 live 库，放弃是安全的。 - 启动恢复加总预算 240 秒（CHATGPT2API_SQLITE_RESTORE_BUDGET），所有库 共用一份 deadline：预算耗尽就先拿空库把服务拉起来，也不让某一个库 拖住整站启动。d8d8989 -
修事件循环被持久卷 IO 卡死导致的整站无响应
xiaolongmr线上日志（2026-10-28 02:35 启动那一轮）里 event_loop_wedged 的线程栈 指向的不是 CPU 算不过来，而是事件循环线程自己在做同步文件读： list_user_options -> public_models_for_identity -> _load_locked -> pathlib read_text 这些文件都在 /app/persist（HF 上是 S3 挂载）。那一轮挂载本身在报 Errno 5，同一时间 skills 同步 180 秒失败、清理 214 张过期图片花了 1048 秒。单次读盘秒级，落在事件循环上就是整站 0 字节响应。 改动： - third_party_images 的 options 端点、accounts 的两个查询端点改走 run_in_threadpool，不再占用事件循环。 - third_party_images.json 与 chatgpt_sessions.json 加进程内缓存 （前者按 5 秒 TTL，后者按 mtime+size 校验），命中期只 stat 一次， 不再每次读全文。 - 模型目录刷新不再在全局锁内做网络请求：正在刷新时其他线程等同一个 结果（最多 5 秒），对话路由直接用手上的缓存不等待；上游全挂时退避 30 秒，避免每个请求都重试一整轮；同类型账号最多试 3 个 token， 不再把几十个限流号挨个串行试一遍。 - 日志改写到容器本地盘。持久卷适合存要跨重启保留的数据，不适合逐行 append：每写一条日志就是一次网络往返。 - 过期图片清理改用 os.scandir 单遍扫描并给单轮设 20000 项上限， 扫不完留到下一轮。 全量测试 949 passed / 31 failed，与改动前基线逐条一致。a439c46 -
dev server 放行整个私有网段，避免 WiFi 换 IP 后 HMR 握手被掐
xiaolongmrallowedDevOrigins 只在启动那一刻求值，启动后再拿到 DHCP 地址就漏了。 普通页面请求不校验 Origin 所以看起来正常，但 /_next/* 与 HMR 的 WebSocket 升级会被 blockCrossSiteDEV 拦掉。改为通配 RFC1918。e84893b -
请求层改用 fetch 适配器，绕开 XHR 被反复重定向的问题
xiaolongmr浏览器里所有走 axios（XHR）的接口都报 net::ERR_TOO_MANY_REDIRECTS， 连 192.168.1.203:3000 这个源也一样；而同一个地址用 fetch 能正常拿到 401/200，curl 打过去也是 200 且 num_redirects=0。项目里没有 middleware， 后端也没有任何 RedirectResponse，所以这不是接口或路由问题，是浏览器把那 条 XHR 请求在内部反复重定向掉了。 axios 1.7 起内置 fetch 适配器，这里显式指定 adapter: "fetch"，请求直接 走 fetch，不再经过 XHR。项目没有用 onUploadProgress（fetch 适配器不支持）， responseType: "blob" 的几处照常工作，线上 apiUrl 为空、同源、没有 withCredentials，行为与原来一致。 实测切完后登录成功、导航 8 项全渲染，之前报错的 /api/chat-room/unread 与 /api/chat-room/direct-conversations 均返回 200。f6daea4 -
导航加载失败时把原因显示出来，并支持点击重试
xiaolongmr之前 /api/navigation 失败是静默的：整条导航直接空掉，只能翻控制台才知道 是 401、跨域还是网络层错误。现在失败时在导航位置显示一枚琥珀色徽标 「导航加载失败（HTTP 401 / Network Error …）· 点此重试」，点一下重新拉取。 成功时清空错误态；仍保留上次成功结果的缓存兜底。00a6ef3 -
dev server 改绑双栈地址，修 localhost 访问异常
xiaolongmrWindows 把 localhost 优先解析成 ::1，而 next dev 之前写的是 -H 0.0.0.0， 只监听 IPv4。于是浏览器每次连 localhost:3000 都要先连 [::1]:3000 失败、 再回落 127.0.0.1，实测 connect 从 1 微秒变成 203 毫秒；HMR/接口一多就更容易 表现为首次加载慢、请求偶发中断。 改成 -H ::（Node 在 Windows 上是双栈通配），实测同时监听 0.0.0.0:3000 和 [::]:3000，localhost 直连 ::1 不再回落，局域网 IPv4 访问照旧可用。e6c4018 -
导航项加载失败时退回上次成功的结果
xiaolongmr顶栏导航是壳数据，一次请求失败整条导航栏就空了。之前只加了对「无 HTTP 状态码 的网络层失败」重试两次，重试仍失败依旧清空。现在按角色把每次成功的结果写进 localStorage，最终失败时读回来兜底，最差也能保留上一次的菜单。存储异常 （隐私模式、配额满）直接忽略，不影响主流程。9f91ec6 -
导航加载在拿不到响应时重试，避免整条导航栏空白
xiaolongmrfetchNavigation 一次失败就直接把导航清空，而这条请求是页面挂载时最早发出的一批。 页面刚加载、切网、休眠唤醒时首个请求可能拿不到响应（error.status 为空），结果就是 顶部只剩 logo 和头像、一个菜单都没有，也没有任何提示。 改为：只有「没有 HTTP 状态码」的网络层失败才重试两次（400ms/800ms 递增）， 服务端已明确答复（4xx/5xx）不重试，避免对错误响应刷请求。9d5791a -
历史导入的图片直接落 blob 仓库，不再绕 base64
xiaolongmr导入时把 zip 里的图片读成 blob，再转成 base64 塞回记录，存储层 persistConversationV2 又把它 base64 解回 blob 存仓库——同一份字节被编码解码一遍，中间还多出 33% 大小的 临时字符串。1.6GB 的历史包在这一步纯属空转。 改为 putResultImageBlob 直接写 image_conversation_blobs，记录里只留 b64BlobKey， 键规则与 persistConversationV2 的 result:会话:轮次:图片 保持一致，重复导入覆盖同一条 而不是堆副本。 顺带补 status：url 与 base64 都清掉后，缺 status 的记录会被 normalizeStoredImage 判成 loading，界面一直转圈；拿到字节就是成功图，显式置 success。625930e -
图片地址跟随当前部署自动改写，换部署不用重新导入
xiaolongmr历史里存的图片地址是生成那一刻的部署地址（127.0.0.1:8000 / img2.z-l.top / zlcy-acm.hf.space）。换部署后这些域名要么失效、要么指向另一台机器，整片历史 图片变破图，只能靠导出再导入修回来。 新增 rebaseImageUrl：所有部署的图片路由都是 /images/<日期>/<文件> 的同一约定， 把「自家部署」的绝对地址折成当前页面 origin，同一份本地历史在任何部署上都能 直接用。只折自家域名（localhost / 127.0.0.1 / *.z-l.top / 两边都是 *.hf.space）， 第三方图床直链原样保留；指向当前后端配置的地址也不折，避免本地开发多一跳。 顺带补 dev 的 /image-thumbnails 代理，否则折到 3000 后缩略图 404。cae12ce -
历史导出清单剥离内嵌 base64 图片
xiaolongmr结果图的 b64_json 是完整 base64 原图（单张 5~16MB），而图片字节本来就会 写进 zip 的 images/{id}.{ext}。清单再带一份等于同一张图存两遍：实测 9 张 图就让 manifest.json 涨到 68MB（占 99.7%），浏览器 JSON.parse/stringify 还要再翻一倍内存。 导出时统一剥掉 b64_json，导入仍按 image.id 从 zip 回填，不受影响。 同一份数据实测：68.00MB -> 0.20MB（333 倍）。 参考图不涉及：它们平时就存在单独的 blob store（storageKey），清单里只有 元数据，dataUrl 为空。653753c -
修复侧栏导出导入按钮被裁切
xiaolongmr侧栏内容区宽度约 228px，而按钮基础样式带 shrink-0 不可压缩， 「新建对话 + 清空 + 导出 + 导入」四个控件最小宽度约 260px， 最后一个按钮被侧栏边界裁掉一半。 把额外操作移到「新建对话 / 清空」下方独立一行，导出与导入各占一半宽度 并补上文字标签，清空按钮改为固定 36px 宽；未传 extraActions 的页面 （商品视觉）布局不受影响。6ba4b86 -
daochu gaicheng chun liulanqi bendi daba
xiaolongmr用户最初的需求是「把这台浏览器上的记录打包带走」，但之前的实现做成了 「导出当前账号在服务器上的任务」：POST /api/image-tasks/export 按 require_identity 过滤 owner，换账号登录就要再导一次，同一浏览器里其他账号 的历史永远导不到。而会话结构本来就只存在 IndexedDB，且 localforage 实例 不带账号前缀（storeName image_conversations，key 是纯 UUID），跨账号的数据 天然都在本地 —— 这个需求只有在浏览器端才做得对。 改动： - 新增 zip-stream.ts：流式 ZIP 写入器，仅 STORED。JSZip 是整包驻留内存， 1.6GB 的历史会直接把标签页撑爆；这里逐条写 FileSystemWritableFileStream， 任意时刻内存里只有当前这一张图。自己实现 CRC32 与 local/central/EOCD 结构。 - 新增 image-history-local.ts：读全部会话，图片按 image.id 存成 images/{id}.{ext}，参考图存 references/{turnId}-{n}.{ext}，manifest 里带 source=local-browser。保存对话框放在最前面弹，避免读完 IndexedDB 后 Chrome 的 transient activation 过期（Must be handling a user gesture）。 - 旧域名的绝对地址统一折成相对路径：历史任务里存着 https://img2.z-l.top/... 这类换部署前的地址，不折的话那批图会全部记成 missing。 - 新增 image-history-local-import.ts：按 manifest 自动区分本地包与服务器包， 本地包直接写回 IndexedDB，不上传。导入时先并发探测图片 url 是否还能取到， 只有取不到的才从 zip 回填成 blob 存储并清空 url（persistConversation 见到 url 会丢弃 b64_json），避免 1.6GB 历史把 IndexedDB 配额撑爆。 - image/page.tsx：导出改走本地打包，带节流…5c1e443 -
daoru lishi jilu shi zidong shibie wai ceng mulu
xiaolongmr用户从线上导出的 image-history-20261028-103246.zip 导入时报「包里缺少 manifest.json」。检查发现包本身完好：manifest 里 2 条任务、1 个会话、 2 张图片都在，只是所有条目被套在了 image-history-20261028-103246/ 目录下 （用解压工具重新压缩会多出这一层），而导入端按根目录读 manifest，于是判定 为「不是本系统导出的包」。 改动： - 新增 _history_prefix()：根目录找不到 manifest.json 时，识别唯一的单层 目录前缀。只接受正好一层，避免误命中 images/ 内部同名的文件；多层或 多个候选一律不猜，仍走原来的报错。 - 读取 manifest 与遍历图片都改用该前缀，图片相对路径照旧做 zip slip 校验。 验证：带前缀的包直接调用导入，imported=2、images=2、会话 1 条；修正成根 目录结构的包走 HTTP 上传同样 200。相关测试 46 项通过。c4b43c4 -
sqlite kuaizhao yasuo kongye bing quxiao guazai jiaoyan
xiaolongmr线上 zlcy/acm 启动耗时 26 分 34 秒，起来之后仍每 30 秒卡死一次。根因是 image_tasks 账本删除旧记录后 SQLite 不回收页：本地同一份库 159.9MB 里 159.3MB（99.6%）是空闲页，真实数据只有 0.6MB（257 条，平均 1.2KB）。 快照机制逐页复制，于是每次备份上传 151MB、每次启动下载 151MB，而每轮备份 还会对挂载上的副本跑一次 integrity_check（151MB 随机读），把容器 IO 占满。 改动： - 新增 _vacuum_if_bloated()：文件超过 16MB 且空闲页占比超过 25% 时 VACUUM。 在快照的本地副本上做（不碰 live 库，避免与业务写入争锁），恢复出快照后 也对 live 库做一次，防止带着空洞继续运行。实测 159.9MB -> 0.50MB，1.5 秒。 - _integrity_ok()：超过 32MB 的库改用 quick_check。它同样能发现结构损坏， 只是跳过索引与内容的交叉核对，在这个量级上快一个量级。 - 上传后不再对挂载副本跑 integrity_check，改为校验字节数。刚写完的文件长度 对不上就能发现截断，真正的完整性校验已经在本地副本上完成。 测试：test_sqlite_mirror_service / test_local_sqlite_split / test_app_startup 共 9 项通过。17fc62f -
镜像复制改用分块读写并限制重试次数
xiaolongmr线上 151MB 的 image_tasks 快照始终读不出来：shutil.copyfile 在大文件上走 os.sendfile 零拷贝快路径，而 HF Storage Bucket 挂载对这类大对象直接返回 Errno 5（同样路径下 2MB 的 accounts.db 却能正常复制）。 - _copy_file 改成分块 copyfileobj（1MB 一块），对网络文件系统更稳，并重试一次； - _prepare_database 连续 2 份快照都读不出来就放弃，避免 5 份候选每份耗十几 分钟、把启动拖到近一小时；放弃后按原有逻辑建空库，应用至少能起来。29172be -
桌面端也能用历史记录导出/导入
xiaolongmr宽屏（lg 以上）用的是常驻侧边栏，没有「历史记录」按钮，那个弹窗根本打不开， 所以之前只把入口放在弹窗里，桌面用户完全看不到。 - ConversationSidebar 增加可选 extraActions 插槽，渲染在「新建对话 / 清空」 同一行；不传就和原来完全一致（chat-room 页不受影响）。 - 图片页桌面侧栏传入两个图标按钮（下载=导出、上传=导入），窄屏仍走历史记录弹窗。 - 文件 input 提到组件顶层：Radix Dialog 关闭时不渲染内容，挂在弹窗里会让桌面 侧栏的导入按钮点不动。2ab5567 -
快照恢复改成先复制到本地再校验
xiaolongmr线上继续卡在 APP_STARTING。上次改对数据来源（优先用 .db 快照）后，卡点 挪到了 _integrity_ok：它直接对网络挂载上的 151MB image_tasks 快照跑 PRAGMA integrity_check，那是大量随机读，正是本文件里早就写明的坑 （"probing ... can make PRAGMA integrity_check perform minutes of random network I/O"）。 改成先 _copy_file 到本地、再对本地副本校验：复制是顺序读，比随机读快一个 数量级；校验不过就删掉换更旧的候选。254a033 -
image_tasks 优先从 db 快照恢复，不再死等 151MB 的 legacy JSON
xiaolongmr上一版只让 legacy 复制失败不崩，但线上仍然起不来：桶里的 /app/persist/image_tasks.json 已 151MB，挂载上顺序读它就是 Errno 5， 而且 shutil.copyfile 要耗十几分钟才抛错 —— 加容错只是把「崩溃」换成了 「干等」，进程照样卡在 APP_STARTING。 而 image_tasks.json 不是可选文件，它是 ImageTaskService 的数据来源， 所以不能简单跳过。改法：先看 sqlite-snapshots/image_tasks/ 有没有 .db 快照， 有就直接用快照恢复（同一份数据的 SQLite 形态，按块读可靠），没有才退回 legacy JSON。老部署（只有 JSON、没有快照）行为不变。 本地实测：走快照恢复后 13 条任务完整。9d2d87b -
图片历史记录支持一键导出与导入
xiaolongmr历史记录弹窗新增「导出」「导入」两个按钮，按账号隔离、合并导入。 后端： - ImageTaskService.export_owned_tasks / import_tasks：导出本人全部任务原始数据； 导入时 task_key 按当前身份重算（不信任包里的 owner_id），同 task_id 跳过， 包里未完成的任务标为 error，避免前端一直等一个不存在的轮询，也不重算积分。 - POST /api/image-tasks/export：打包 zip，含 manifest.json、会话结构、任务与 原图（images/ 相对路径与 /images/<rel> 一致）。图片已是压缩格式，用 STORED 存储省 CPU。导出后由后台任务删临时文件。 - POST /api/image-tasks/import：限 8GB 解压上限、逐条校验路径防 zip slip， 图片落到 images_dir（已存在则跳过），并把记录里的图片地址重写到当前部署。 前端： - 会话结构（标题/分组/轮次）只存在浏览器本地，导出时一并上传进包，导入时 写回本地存储，否则导入后标题和分组会丢； - 导入后把会话里的图片地址改成本站相对路径，换部署也能显示； - 按钮带 loading 与结果提示（新增/跳过/图片张数）。 实测：导出 13 条记录 + 5 张图 12.5MB；重复导入返回 skipped=13 imported=0； 坏包与格式不符均返回 400。35a279e -
镜像恢复遇到读不了的 legacy 文件不再拖垮启动
xiaolongmr线上 zlcy/acm 挂上真实数据桶后一直卡在 APP_STARTING，run 日志里是 OSError Errno 5：shutil.copyfile 复制 /app/persist/image_tasks.json （151MB 的历史 JSON）时 I/O 报错，异常直接冒出 runtime_file()，整个进程 启动中断 —— 而它后面本来还要从 sqlite-snapshots/image_tasks/*.db 恢复。 改动： - runtime_file() 复制 legacy 文件失败只打印并跳过，legacy 只是历史导入源， 真正的数据在 *.db 快照里，不该因为它起不来； - _prepare_database() 单个快照复制失败改为试下一个候选（更旧的快照）， 避免一个坏快照顶死整个库； - _salvage_database() 的兜底异常从 sqlite3.Error 扩到 OSError，网络挂载 上的 I/O 错误不一定被包装成 sqlite3 异常。8478824
10 days ago
-
放行穿透域名的 HMR WebSocket 升级
xiaolongmrNext 16 的 allowedDevOrigins 不只拦 /_next/* 静态资源，HMR 的 WebSocket 升级也要校验 Origin。经 FRP 用 img2.z-l.top 访问时，静态资源能过、但这 条升级被判为未登记来源而拒绝，控制台持续报 "WebSocket connection to wss://.../_next/webpack-hmr failed"，热更新失效。 把 z-l.top（FRP 自定义域名）与 hf.space（hosts 指向本机时的 Origin） 一并按通配符登记，今后换子域名或换隧道都不必再改代码。c45dcf8 -
放行内网穿透域名的 dev 跨源请求
xiaolongmrNext 16 会按 Origin 比对 allowedDevOrigins，未登记来源访问 /_next/* 直接 403。 经 FRP 穿透时 Host 与浏览器 Origin 常常不一致（Host 被改写成 127.0.0.1:3000）， 会被判定为跨源而整页资源加载失败。 把共享穿透域名 * . seedance.kdns.fr 一并登记，换子域名无需再改代码。5c57381 -
微信登录不再被会话残留的死代理毒死
xiaolongmr本地会话每次注入的 HTTP(S)_PROXY 端口都会变，后端进程里可能残留上一次 启动的死端口；httpx 默认 trust_env=True 会盲用它，ConnectError 之后被 统一转成 502「微信登录服务暂时不可用」，排查时没有任何日志可看。 改为直连优先（wx.z-l.top 是公网 HTTPS，直连即可）、失败再退回环境代理 兜底，既绕开死端口，又保留需要代理的极端网络下的可用性。 配套（仅本地、artifacts/ 已 gitignore）：本地启动器把后端 env 代理钉到 稳定的 7890，覆盖会话注入的死端口，顺带修好 model_catalog 的 ConnectionError。0402839 -
init
xiaolongmr85270f9