GitHub 似乎數不好東西 （★ 64 分）
文章指出 GitHub 出現兩項明顯的介面計數異常。其一是儲存庫的合併請求（Pull Request, PR）分頁標籤會多算數量：完成合併後尤其常見，標籤顯示有兩筆 PR，實際清單卻只有一筆。其二是組織清單的分頁失效；作者因長年加入許多組織，必須前往第二頁尋找要與 Sentry（應用程式錯誤監控服務）串接的專案，但頁碼列只顯示第一頁、第三頁與下一頁，第二頁完全消失。由於彈出式視窗無法直接修改網址，作者只好在瀏覽器開發者工具以 JavaScript 強制跳轉至目標頁面。
討論者普遍認為，問題很可能源自不同資料來源未同步，例如主要資料庫與 Elasticsearch（分散式搜尋索引引擎）之間出現延遲，或多層快取保存了不一致的結果。有人指出，GitHub 的議題與 PR 清單可能改由搜尋索引供應資料，因此使用者剛完成關閉、合併等操作時，畫面未必立刻反映最新狀態。這類最終一致性（eventual consistency，資料短暫不同步後才逐步一致）的設計在大型服務並不罕見，但評論者認為，至少應避免同一頁面同時呈現互相矛盾的計數與清單。
不少人分享更影響工作的案例：已核准的 PR 仍顯示等待審查，造成案件延誤數週；GitHub Actions（GitHub 的自動化工作流程服務）排程可能晚數小時觸發，甚至完全未執行；API（應用程式介面）查詢進行中的工作流程時，也會在數秒內忽隱忽現。另有使用者表示，多年前的 PR 無法在搜尋結果或分頁清單找到，卻仍可由直接網址開啟。有人因排程不可靠，已改用 AWS（Amazon Web Services）EventBridge Scheduler 與 Lambda 處理觸發工作。
社群對嚴重程度看法不一：較寬容者認為，這是大型組織常見的快取不同步問題，把它稱為「嚴重」或許過頭；批評者則認為，當計數、審查狀態、排程與 API 輸出都無法信賴時，已不只是表面瑕疵，而是可靠性與產品品質問題。也有人把 GitHub 近年的狀況歸咎於 Microsoft 收購後的策略，認為資源過度投注在 Copilot 等 AI 功能，忽略基礎穩定性；不過這項歸因主要屬使用者推測。另有留言指出，未獲儲存庫存取權前就能看到議題數量，可能還涉及資訊揭露風險。
👥 45 則討論、評論 💬
https://news.ycombinator.com/item?id=49730302