20260929 會議記錄

:::info

• 所有會議記錄

  編輯當週文件

  準備

  總結

• 9/29 (二) 20:00
• NPO Hub 出席：bil, mrorz
• 線上出席：nonumpa, yutin
• https://meet.google.com/mrz-dgrd-pri :::

上週待辦

• 追蹤 devops#17：rumors-site / line-bot-zh / url-resolver 記錄 request header，並修 rumors-api GraphQL log header 迴歸
• 追蹤 devops#18：記錄 Cloudflare Analytics retention（31 天 / 3 天）與 Logpush Enterprise-only 限制
• cofacts.ai session 週報：GGM 手動貼到 #collab；MrOrz 準備 DC bot 之後自動化
• nonumpa：繼續研究 FB / IG preview 仍是登入畫面的問題
  • threads 要特別處理：title 不能拿 og-title，順便把還沒改完的一起改 –> in PR #74
  • PR #74 之前有 extracts static，其實用處不大（case 很少），會先拔掉
  • Threads 變動
    • 單純 fetch user agent 放 Cofacts-bot
    • puppeteer 會放一般使用者會放的 UA
    • post unavailable 時會 redirect 到 error 網址，特別處理它回應說是被移除，url resolver 拿到的才會比較正確
• MrOrz：cofacts.ai 前端先打底（frontend skill + storybook），之後請 yutin 接手
  • 等等討論新 design doc
• rumors-api#388 vector search：補 userId / appId backfill
  • 部署後驗證 embeddings 真正寫入 / 讀取（schema 已於 9/14 上 staging & production）
• 推進 ai#118（URL resolver pre-flight 檢查，補 hyperlinks 參考邏輯）
• Staging VPS OS 太舊（Ubuntu 16.04 / 2018 kernel），Node 18+ 完全跑不動，排 OS 升級
• 建議：site-tw CPU/Mem p99 長期貼近 1 vCPU / 1GB 上限，列入擴容評估
• url-resolver#74：Threads 410/redirect 處理、puppeteer UA 設定，希望這週 ready for review
• 追蹤 cofacts/ai#146：relatedArticles 誤導防護（見 0922 會議記錄）
  • –> track in Github Project
• 追蹤 devops#23：Langfuse v3 → v4 升級，But
  • Staging 很老、disk 不確定是否足夠
  • Staging 機器換地方？
  • Staging 架在自己的 laptop?
    • 驗證 Cofacts 全系統可以帶著走
  • or Langfuse 獨立一台？

    [!Note] TODO 把以上 consideration 加到 devops#23

cofacts.ai

Vector search

@MrOrz：試著把 PR#400 部署到 staging，用 staging LINE bot 傳影片測 e2e，確認 rumors-api 轉傳 URL 給 Vertex AI 後能正常運作。一路上遇到不少雷，但和實作無關，是資料流上的小眉角，細節在 PR comment。

@MrOrz：用 HTTP URL 的話，agent platform 只能傳 15MB（文件）。LINE 影片很容易超過 15MB，PR#400 可能沒辦法出 QQ @yutin：Copy that，我想一下怎麼解，週一處理

@MrOrz：embedding API 沒寫大小限制，但如果都傳了 GCS，或許 embedding 也一起用 GCS 比較順。另外 embedding 有 task instructions，該用 search result 還是 fact checking？ @yutin：沒有大小限制，但有長度限制；可以裁切範圍內的長度，只做部分搜尋？ @MrOrz：超過長度會 4XX 還是自動截斷不清楚。不存檔就截斷較複雜，存檔要注意 disk。覺得截前 120s 還行；之前 design doc 是希望每段時間切，schema 也有預留一份文件存多個 embedding。

refactor(transcript): 直接把 media URI 交給 Vertex，不再複製到 GCS #400

• Vertex AI 直接給 URL 的話只能傳 15MB（文件）
  • 此 refactor 應該不會 merge
• Embedding 的部分不確定是否有檔案大小限制
  • 想直接 stream 過去 [name=yutin]
  • 之前測試都允許 stream 上去，時間長度過長會回傳 media 太大 [name=yutin]
    • Gemini & Vertex AI API 都會這樣
    • Gemini API 無法太多檔案
  • 如果給 gcs:// 那檔案容量會比較寬容嗎？ [name=mrorz]
    • 沒試過
    • 如果它能幫我們自動擷取前面是最好 [name=yutin]

Site revamp

doc(cofacts.ai): Phase 3 網站遷移與前端架構 design doc #31（opened 2026-09-28）

• Oct W1~2 –> 收尾手上的東西
  • yutin: embedding
  • mrorz:
    • cofacts/ai PR：送出新訊息、url-resolver 整合、storybook 初始設定
    • 要和設計師確認「附錄 C：與設計師 sync 的差異清單」 https://github.com/cofacts/kb/pull/31/changes
  • nonumpa: 新版 URL resolver
• +1 contractor
• Oct W3: cofacts.ai 前端基礎處理好
• Oct/E ~ Dec
  • 需同時進行 https://github.com/orgs/cofacts/projects/12 裡的 revamp

• nonumpa may have limited capacity on November

Cofacts article classifier

https://github.com/cofacts/kb/pull/29

[!Note] TODO MrOrz 把 key 丟給 AI 讓他做實驗 再回頭更新 kb#29、給大家 review

小聚 rundown

• 10/03 (六) 板橋中心（新北市板橋區文化路二段 242 號 6 樓 604 室）//(華梵大學推廣教育處/龍山寺文化廣場)一般教室604
• 週五早上
  • KKTIX 行前通知：提醒時間、使用電腦而非手機

    Hello 你好，

    本週六就是查核志工培訓囉！

    志工培訓需要大量查詢資料，請自備筆電 💻 與充電器 🔌 並帶著愉快的心情來參加。帶順手的平板也可以的！Cofacts 資料庫也有很多影音謠言，請自備耳機唷 🎧！

    🕒 時間：（六）14:00 - 17:00 📍 地點：新北市板橋區文化路二段 242 號 6 樓 604 室

    費用全免，會很準時開始。若不克前往，記得取消報名 :)

    Cofacts 真的假的 查核協作 VIP 臉書社團在這裡 👉 https://www.facebook.com/groups/cofacts Cofacts 真的假的 查核協作 Discord 在這裡 👉 https://cofacts.tw/discord 說你會來查核小聚優先加入 ＝Ｄ

    感謝你的閱讀。

    那麼明天見囉😊

    比鄰敬上

  • 55次小聚 KKTIX https://cofacts.kktix.cc/events/cofactseditor55
  • 開場使用材料更新（含 cofacts.ai 介紹：期待的用法、點開 tool call 看細節、複製 fact check response 或繼續 tune、查出處是否存在、遇到錯誤記得倒讚）
  • 準備 Slido #cofacts
• 當日準備 / 攜帶
  • 樓下用的標語
  • 拍照用大布條
  • 貼紙
  • 黏土
  • 手板
  • 講義
  • 一次性杯子
  • 延長線（場地有 6 個插座、現場兩條延長線，建議再帶 5 條）
  • Wifi 機（rt-ax57 go + 電源線）
  • 多帶一條 type-c 公公線 for dongle 的電
  • 備用 wifi 機
• 13:00 - 場佈
  • 簽到（問飲料）
  • 排桌子椅子
  • 投影位置？
  • 麥克風
  • 延長線佈置
  • 門口黏引導牌
  • WIFI：佈機，手機 USB 選擇網路分享，等待白燈亮；用 ASUS Device Discovery 確認可連線到 ASUS
  • 投影的電腦用 google chrome 開好（投影片 / Bignum / KKTIX / Slido admin / Slido / 開場影片 / BGM / Analytics）
• 14:00 - 14:20 開場：放長影片（8min）、場地、Slido、Cofacts 機器人系統簡介
• 14:20 - 14:40：引導 註冊網站、介紹評價現有回應
• 14:40 - 14:50：實作評價（從網站找訊息按讚）
• 14:50 - 15:10 介紹補充資訊
• 15:10 - 15:40 實作補充資訊、自我介紹、休息（閒聊「看到覺得最好的回應、覺得哪裡好」）
• 15:40 - 16:10：介紹撰寫新回應
• 16:10 - 16:40：實作撰寫新回應（挑選「一篇」最有興趣的回應）
• 16:40 - 17:00 介紹 RSS、社群、合照

場地想法摘要 — 板橋中心（下次小聚同場地）

來源： 20260818 小聚檢討 / 小松果

• 地址/容量：新北市板橋區文化路二段 242 號 6 樓 603 室，30 人教室
• 桌椅：9 張 3 人桌，中間前面改 2 人桌（因夾著投影機）；延長線從教室後方往前拉，避免絆腳；門旁邊有 4 個連桌椅位子最擠；門外可設接待桌
• 飲食：教室內可以吃東西，但用畢需整理乾淨
• 麥克風：場地只能提供一支麥克風
  • 密閉空間，也還行 [name=bil]
• 電力/插座：場地有 6 個插座，現場備 2 條延長線，籌辦時建議再多帶 5 條
  • bil 會帶 5 條
• WiFi：網路整體穩定，但曾有一人連不上（wifi router 最後只有 5 個裝置連線）
• 出席狀況：報到率高，大多數人準時抵達

上週重點整理（2026-09-22 ～ 2026-09-29）

GitHub 活動

cofacts/rumors-api

• fix(transcript): replace gemini-2.5-flash fallback with gemini-3.5-flash-lite #405（opened 2026-09-26）

cofacts/ai

• Issue #146 relatedArticles 相似度搜尋在裸網址情境下可能誤導查核（增加防護 + 教 AI 重用機制）（opened 2026-09-28）
  • –> Add to project, will track in project

cofacts/devops

• Document AI bot policy and 2026-09-20 verified-bot rule change #21（merged 2026-09-22；同時關閉 #12 user-driven 爬蟲存取政策）
• Note Huang Daniel’s batch-upload pace as known-legitimate #22（merged 2026-09-26）
• Issue #23 追蹤 Langfuse v3 → v4 升級（v3 將於 2027/1 EOL）（opened 2026-09-28）

cofacts/kb

• research(cofacts.ai): OpenFun 資料 Subagent 可行性與必要性研究 #28（merged 2026-09-22）
• docs(research): 中央社 CNA MCP — 能力觀察與 cofacts.ai 整合評估 #25（merged 2026-09-24）
• doc: add 20260922 meeting notes #30（merged 2026-09-28）

cofacts/takedowns

• Takedown spam user Zhou Ye #356（merged 2026-09-25）
• Takedown spam user 娃娃 #357（merged 2026-09-25）

cofacts/cofacts-ai-eval

• Add weekly usage review for 2026-09-22 #18（merged 2026-09-22）

LINE Bot request_timeout 調查彙整

調查期間：2026-09-24 ～ 2026-09-29 觸發原因：production LINE bot（Cofacts 真的假的｜轉傳查證）持續收到 LINE 的「bot server returned no response or an error」通知信，但手動測試（tutorial、影片查證）都正常。

結論先講：找到兩個確定的根因並修掉了，但不確定問題是否已經完全解決，還額外挖出一個舊的未解謎團

一、症狀與資料來源

• LINE Developers Console 的 bot error stats（request_timeout on POST /callback）
• Cloudflare GraphQL Analytics API（httpRequestsAdaptiveGroups，逐請求層級的 edge 資料）
• GCE cofacts-prod 上的 Cloud Logging（gcplogs-docker-driver，line-bot-zh 的 application log）
• journalctl / dmesg（OS 層級事件）

錯誤從至少 2026-09-11 就存在（Gmail 訂閱信可查），9/21～9/24 明顯加劇（LINE 統計：30 → 55 → 40 → 96 次/天），之後回落。

關鍵前提：確認 /callback 流量本身在整段期間持平（每天 9,700～13,000 次，無成長趨勢）——不是使用量變多造成的。

二、根因 #1：Node 預設 keepAliveTimeout（5 秒）與 reverse proxy 連線重用視窗不匹配

• rumors-line-bot/src/index.js 的 app.listen() 從未設定 keepAliveTimeout／headersTimeout，用 Node 預設 5 秒。
• 前面是 Cloudflare Tunnel（cloudflared），會保留、重用比 5 秒更久的 keep-alive 連線。
• Node 在閒置 5 秒後主動關閉連線，若此時 cloudflared 剛好要重用同一條連線送新的 webhook 請求 → 連線已死 → LINE 收不到回應 → 記錄成 request_timeout。
• Cloudflare edge 資料佐證：/callback 上 499（client/edge 等到放棄）有 300 次，真正的 502（origin 主動回錯）只有 6 次，符合「連線被晾在那沒人接」的特徵，而非 app 邏輯出錯。

修法：server.keepAliveTimeout = 65_000、server.headersTimeout = 66_000（拉到明顯大於 proxy 的重用視窗）。

PR：cofacts/rumors-line-bot#416 — 已 merge、已部署（2026-09-26 08:21 UTC 重啟生效）。

效果：部署後，「短時間內同一分鐘炸裂好幾筆」的密集錯誤模式消失了；但零星、單筆的失敗並未歸零，代表這不是唯一成因。

三、根因 #2：每小時的 PM2 reload（cron）在 SIGINT 時沒有優雅關閉

查 /etc/cron.d/cofacts-ops 發現：

# Chatbot group 重啟（穩定性維護）
15 * * * *  root  cd /srv/rumors-deploy && docker compose exec -T line-bot-zh node_modules/.bin/pm2 reload all ...

line-bot-zh 每小時被 pm2 reload all rolling-restart 一次（透過 Cloud Logging 查證，至少從 9/14 起、每小時精準地在 :15:0X 秒發生）。

• pm2 reload all 對舊 worker 送 SIGINT，但 src/index.js 原本的 SIGINT handler 沒有呼叫 server.close()，直接 redis.quit() 後 process.exit(0)——舊 worker 手上任何 keep-alive 連線（含閒置中的）都被瞬間砍斷，不管 Node 自己的 keepAliveTimeout 設多少。
• PM2 預設 kill_timeout 只有 1.6 秒，就算想優雅收尾也沒時間。
• 時間點對得上：部署 #416 之後殘留的失敗裡，換算成 UTC 後有兩筆精準落在 :15:15（reload 那一分鐘），隨機撞上同一秒附近的機率極低。

修法：SIGINT handler 加 server.close()（先停止接受新連線），ecosystem.config.js 的 kill_timeout 拉到 15 秒（給收尾時間）。

PR：cofacts/rumors-line-bot#417 — 已開，尚未 merge / 部署。

四、意外發現：一次獨立的、跟上述都無關的當機事件

9/22 台灣時間凌晨 03:34～04:56，Cloudflare 自己內建的 health check 打 line-bot.cofacts.tw/ 有 ~30% 收到 502（持續約 50 分鐘）。查了 dmesg／journalctl，沒有 OOM、沒有 container 重啟紀錄——origin 當下應該是「活著但卡住沒回應」，原因不明（舊 container log 已隨 9/26 部署被換掉，回不去查了）。這單一事件把 9/22 當天的錯誤數字拉得特別高，跟根因 #1、#2 是分開的事，暫時懸而未決。

五、順著 cron 註解「Chatbot group 重啟」牽出的舊謎團（尚未解決）

• 這個 cron 的原始目的，據 Johnson 回憶，是拿來解決「群組訊息處理有時候沒回覆」的問題——用定期重啟當作 workaround。
• 查 git log：src/webhook/handlers/groupHandler.js 用 Bull queue 處理群組訊息，有一段刻意設計的「過期事件暫停/恢復」邏輯（84c9d2e，2018年commit，設計意圖：有新事件時暫停處理過期事件）。
• Johnson 自己在 2023-02-06 就寫過 debug commit（ad63cf8：「Add debugging log to group - Helps check why group chatbot has no reply when the queue still works」），後續又加了 GraphQL queue 監控端點——顯示這個「群組有時候沒回覆」的謎團至少 3 年前就存在、當時也沒真正查出根因，只留下診斷工具。
• 這次重新檢查程式碼，發現 pause()/resume() 沒有帶 Bull 的 isLocal 參數（理論上在 production 實際跑的 3 個 PM2 cluster worker 之間，這是全域生效的暫停，可能有「暫停後沒人恢復」的風險）。但嘗試修正後發現：
  • 會直接弄壞既有測試（groupHandler.test.js 斷言 Bull 的 paused job count，只有全域 pause 才會出現這個數字）
  • 會讓 2023 年加的 GraphQL 監控（QueueInfo.isPaused）失去效用
  • 重新想過 Bull 的 'drained' 事件其實會廣播給所有 worker，不是只有暫停者能恢復，所以「永久卡死」的推論也沒有很確定
  • 最終沒有送出修復 PR，決定先不動這段 code，避免弄壞更多東西卻沒解決真問題。

這部分是真的「空手而回」——只找到線索、沒有結論，值得帶去會議上讓其他人一起想。

六、目前狀態與待決事項

七、想帶去會議討論的問題

1. 9/22 凌晨那次 origin 卡住（非 OOM、非重啟）還有沒有人有印象／猜測？要不要加更持久的 log 保存，下次再發生能回頭查？
2. Group 訊息「有時候沒回覆」這個 2023 年就有的謎團，有沒有人記得更多背景，或當時排查到什麼程度？
3. Cron 重啟頻率該怎麼權衡（webhook 穩定性 vs. group queue 卡住的自癒時間）？

Related PRs

cofacts/rumors-line-bot

• fix: raise server keepAliveTimeout above cloudflared’s connection reuse window #416（merged 2026-09-26）
• release/20260926（released 2026-09-26）
• fix: gracefully stop accepting connections on SIGINT before PM2 kills the worker #417（opened 2026-09-28）

GCE（cofacts-prod）主機

每格依序是 min | avg | p95 | max（%）。

* 09-29 只有半天資料。

目前狀態： 已連續運行 145 天，load average 為 1.28 / 0.90 / 0.83。記憶體用 21 GiB / 31 GiB（還有 9.6 GiB 可用），Swap 用 1.9 GiB / 4 GiB。硬碟 71%（48G / 67G）。

GCE 主要程序（跟上週 9/15–9/22 比）

CPU 單位是 core（核心數）。

Cloud Run

部署： 9/26 重新部署了 line-bot-tw、line-bot-en、line-bot-ja 和 dev-line-bot，所有服務狀態都是 ✔。

流量（Network Out）

site-tw 的流量在 9/23–9/24 最高，9/27 以後明顯回落，9/28 降到 3.48 GB。這跟 6 月開始的 egress 降費任務有關，建議看一下 Cloudflare 那幾天是否有新的爬蟲，或是 WAF 規則沒擋到的流量。

本週重點

1. ✅ GCE 很穩：CPU 平均 13–20%，記憶體約 67%，Swap 維持在 47–49%，這幾項跟上週差不多。
2. ⚠️ site-tw 資源貼齊上限：記憶體 p99 為 1.01，CPU p99 約 1.0，連續兩週都這樣。建議優先處理。
3. ⚠️ site-tw 流量增加約 30%：尖峰在 9/23–24，之後已回落，要確認是不是爬蟲造成的。
4. ℹ️ GCE 硬碟 71%：還有 20G 可用，持續觀察即可。

所有摘要檔都存在 workspace/metrics/，檔名含 2026-09-22_2026-09-29_1790652244。