這是由 DEV 的 Summer Bug Smash: Smash Stories 與 Sentry 共同贊助的投稿。
這件事發生在我曾經任職的某家大型企業，已經是好一陣子以前了。
當時我是全端工程師，負責一個 Web 應用程式的前端與後端。
因為那家企業非常龐大，所以有不少由不同團隊共用、並由專職開發者維護的函式庫與服務。某種程度上來說，就像是在企業內部做開源。:smile:
當然，我們也用了其中一些函式庫與服務，畢竟能重用別人的成果，何必重新造輪子，對吧？
於是，在我們發佈 Web 應用程式的第一版之後，一個有趣的 bug 出現了。
當使用者在多個瀏覽器分頁中開啟應用程式時，其中某個分頁的驗證有時候會隨機失效。一旦發生，除非使用者按下 F5 或把該分頁完全關掉，否則那個分頁就再也無法恢復。
很有意思。
身為團隊中的資深開發者，我接下了這個 bug 並開始調查。
經過一段時間與大量嘗試之後，我發現前端在嘗試重新整理驗證 token 時，收到的是 403 Forbidden 的 HTTP 回應，導致整個驗證流程完全中斷。
於是我開始在 Chrome 裡反覆操作 sessionStorage 與 localStorage，也嘗試調整驗證設定。雖然幫助不大，但有一點很清楚：這個 bug 看起來是在共用的前端驗證函式庫裡。
好吧。
我把所有 log 和我對這個 bug 的理解整理好，然後去找負責維護驗證函式庫的前端團隊。
經過一個小時的討論後，他們得出的結論是：這不是他們的問題，因為負責維護驗證服務的後端團隊不應該回傳那個特定的回應碼。
是的，前端函式庫和後端驗證服務是由完全不同的團隊維護的。
我不是完全信服，但人多勢眾。:grin:
所以我又把所有 log 整理了一次，然後去找後端團隊。
我們又討論了一輪，最後發現他們回傳的回應碼其實是合理的，因為前端驗證函式庫送出的 refresh token 早就已經失效了。真正的問題是多分頁之間的競態條件：其中一個分頁刷新了 token，並使前一個 refresh token 失效，但另一個分頁還在嘗試使用它。
好吧……
於是我再次拿著所有 log 回到前端團隊。
如果你在想，為什麼這兩個團隊不直接彼此溝通，兩邊給我的答案大致相同：
這是你們應用程式的問題，所以你們團隊必須自己解決。
再回到前端團隊。
我把後端團隊的結論說給他們聽，但他們還是沒有被說服。
那時我開始有點火大了，所以我建立了一個單一工單，把兩個團隊都加進來，並附上我蒐集到的所有 log、請求、回應、時間戳記，以及其他所有資料。
幾週過去了。
工單裡和聊天中仍然持續在討論。
但 bug 的解法看起來還是遙遙無期。
所以我決定安排一場所有相關人員都參加的會議。
然後，事情終於有了進展。
在會議中，我們同意問題出在前端驗證函式庫，而前端團隊會修正它。
成功了！
至少我當時是這麼想的。
兩週後，測試人員和使用者因為應用程式隨機無法刷新驗證 token 而越來越不耐煩，前端團隊帶回了他們的最終結論：
他們無法重現這個問題。
而且使用者不應該在多個分頁中開啟應用程式。
直到那一刻，開啟多個分頁都被認為是完全正常的使用流程……
於是我在那一刻關掉工單，將我們專案中那套企業內部的前端驗證函式庫整個移除，並直接針對既有的企業驗證服務，重新實作了整個客戶端驗證流程。
主要的改動集中在 Angular 的 HTTP interceptor 與 token 重新整理流程。我更新了 interceptor，讓它能處理與驗證相關的回應，包括 403 Forbidden，而不會讓整個分頁卡死在損壞狀態。
我也重新設計了刷新後 token 的處理與儲存方式。現在，失效的 token 與刷新失敗的嘗試都會被明確處理，而不是讓驗證流程直接完全停止。
是的，這花了我兩天一夜。也沒錯，我從企業內部的驗證函式庫借鑑了一些想法，否則還會花更久。:smile:
但我只有一份神經。
你知道嗎？
從那之後，一切都運作得非常順暢。而且每當又出現新的 bug 時，都能立刻修掉，因為這次我們真的擁有那份程式碼。
這就是我的 Bug Smash 故事：企業生活有時候真的有點荒謬，而修一個 bug 可能意味著得把整個功能重寫一遍。
<!-- 別忘了替你的文章加入封面圖片，並加上其他適當的標籤。 -->
<!-- 感謝你的參與！ -->
原文出處：https://dev.to/gramli/how-i-smashed-a-bug-in-a-shared-authentication-library-33fm
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
