Facebook SDK 錯誤回報的修改：如何避免只修到表面症狀

在上一篇文章中，我整理了 Facebook SDK 錯誤回報從 #1799、#1806 到 #1847 的演進。這篇不再重述修改內容，而是回頭檢視：為什麼問題需要經過多次修改才逐漸收斂？之後可以如何提高一次修正到位的機會？

先分清楚功能問題與監控問題

面對 Rollbar 的大量錯誤時，應先拆開兩個問題：

1. 使用者的功能真的壞了嗎？
2. Rollbar 的事件能準確代表功能壞了嗎？

在這次案例裡，Facebook SDK pending 超過 10 秒是技術狀態；使用者正在登入，卻因 SDK unavailable 而無法操作，才是產品問題。兩者相關，但並不相同。

如果使用者只是在瀏覽公司或文章頁面，即使背景 SDK unavailable，也不代表登入功能正在影響他。監控事件若沒有包含使用者意圖，就可能把資源異常誤解為使用者問題。

先定義想觀測的事件

動手修改前，可以先用一句話定義事件：

我們想知道有多少使用者已經看到 Facebook 登入介面，但因 SDK 連續 10 秒 unavailable 而可能無法登入。

接著再檢查現有程式實際回報的是不是同一件事。

這次 ER0022 原本只能表示初始化 Promise 在 10 秒內沒有 resolve 或 reject，不能直接推論 SDK 一定下載過慢、使用者正在登入，或事件一定來自爬蟲。先釐清事件的真正語意，才能避免用錯誤的假設設計修正方案。

區分事實、推測與未知

分析監控資料時，可以將資訊分成三類：

• 事實：Provider 掛在全站、所有頁面都會啟動 timeout、部分環境短時間開啟大量網址。
• 推測：這些流量模式很像爬蟲，自動化環境可能沒有完整完成第三方 SDK 初始化。
• 未知：SDK 是否下載完成、所有事件是否都是爬蟲、Promise pending 的確切原因。

推測可以協助提出假設，但不應直接變成程式判斷。例如 navigator.webdriver 適合作為分析資訊，卻不足以單獨決定是否忽略錯誤。

實作前先列出情境與非目標

這次真正需要的行為可以先整理成一張小表：

同時也要明確寫出非目標：這次不改成按需載入 SDK、不辨識或封鎖爬蟲、不修改 Facebook widgets，也不處理多分頁登入同步。

有了這個邊界，便能判斷某項修改是在解決目前問題，還是在順便重構另一套機制。

選擇最小的因果修改

判斷方案是否過度設計時，可以問：

如果只移動錯誤回報的觸發位置，就能讓事件語意正確，是否真的需要重構整個 SDK 載入架構？

這次的問題是回報時機與登入意圖無關，因此將 timeout 從全站 Provider 移到登入 UI，是直接切斷錯誤因果的修改。

若同時改成按需載入，還需要處理登入按鈕狀態、首次點擊、retry、widget lifecycle 等問題。這些改進並非沒有價值，但應在有獨立需求與量測證據時另開修改。

把情境轉成驗證項目

實作後不應只驗證「錯誤數量會下降」，而要確認事件語意與功能都正確：

• 普通頁面經過 10 秒不回報。
• Login Modal 關閉時不回報。
• Login Modal 或 /inbox 登入畫面顯示，SDK unavailable 10 秒後回報。
• SDK 在 10 秒內 ready，或 Modal 提前關閉時取消回報。
• SDK 較晚 ready 時，Facebook Context 仍能恢復。
• 實際登入錯誤仍由既有流程回報。

上線後除了觀察 ER0022 數量，也要抽查每筆事件是否都帶有 login-modal 或 inline-login，並確認 Facebook 登入成功率與既有登入錯誤沒有惡化。

結語

真正需要避免的，不是修改次數本身，而是在沒有重新檢查問題定義的情況下，一次次只修到表面症狀。

之後遇到類似問題時，我會依序確認：真正的使用者問題是什麼、監控事件實際代表什麼、哪些是事實或推測、修改邊界在哪裡，以及上線後如何證明事件品質和產品行為都符合預期。

當問題定義、事件語意、修改範圍與驗證標準一致時，才更有機會讓修正一次收斂。