markkwsu有一組 Firestore Listener 在背景執行很久了，但最近常常掛掉。
把錯誤訊息分享（2022/3/13 分享）在 stackoverflow 卻得不到什麼回應，前幾天有個老外回覆說：「我也有遇到這樣的問題」，但因為違反 stackoverflow 的規定，所以被系統自動刪文。
後來想想這樣也不是辦法，就在 2022/4/10 透過電子郵件聯繫了 Firebase Support，而這個開端，讓我開始對 Google 越來越像 IBM 這件事，有更深刻的感受；在開始寫這篇文的時候，這個問題 Firebase Support 還沒有給一個能解的方法，我會持續的更新這篇文章，直到這個問題被解決為止。
2022/4/10 15:02 收到自動的電子郵件回覆，說有收到這個 case。
2022/4/11 20:55 收到 Support 寫來的電子郵件，要求提供相關資訊，很正常的處理流程。
2022/4/11 21:56 我把回覆的電子郵件寄出，提供該給的資訊。
2022/4/13 18:41 收到回覆，然後開始有無限迴圈的感覺。你問我為什麼會有這種感覺？因為我過去跟國際大嘴巴的 Support 玩過太多遊戲了。
2022/4/13 21:58 我回信的內容已經開始不客氣了。
2022/4/15 19:17 收到回信，就如同我過去的經驗一樣，要我收集更多資料給他；有注意到他反覆提出 quickStart 這件事嗎？這是這篇文首發的時候，一個很重要的點。
2022/4/17 16:01 我回信了，會拖了一天才回信的原因是：我依照他的要求寫了一個最小可行的範例來跑，也在我預期的狀況下，發生相同的 exception。
2022/4/19 20:16 Support 回信了，完全忽略我給他的東西，再次強調在 quickStart 的環境下，應該不會有這樣的問題；走到這裡最好笑的部分就要開始了，所以他的意思是全世界有使用 Firebase solution 的開發者，都一定要用 Firebase 的 quickStart 去建置他的系統；如果你不用 quickStart 的架構去建置你的系統，他就會用這個方式持續的刁難你。
2022/4/19 21:58 我回信了，很客氣地問他，是不是在 github 上面的那個 java quickstart。
2022/4/21 13:13 Support 回信了，說：「是的！沒錯！請服用 quickstart！」
事情發展到這邊，我們可以來順一下邏輯：
- 我已經很清楚的告知我們是使用 Java Language 在開發。
- 我已經很清楚的告知我們是使用 Firebase 的官方 Java SDK。
- 我已經寫了一個最小最小的程式（也是 Support 要求的），也附上 source code，只要有 JDK/JRE 去執行 java -jar，就可以看到我們的問題。
然後 Firebase Support 要我去服用 java quickstart。
其實也不是我不願意去服用 java quickstart，而是這個 java quickstart 我已經先看過了，大概有以下幾個問題：
- 這個 java quickstart 其實沒有什麼在維護，最近的一次異動是在十個月前，大多數的異動都在三到五年前；並且 build.gradle 裡面的 firebase java admin 版本還在 5.9.0（現在已經是 8.1.0），而且許多因為 gradle 本身版本已經演進而廢止的語法也都還在。簡而言之，你沒有辦法從 github 下載下來後，簡單執行 gradle 或是 gradle build 就可以看到結果。
- 這個 java quickstart 沒有我遇到的問題「Firestore」套件的 quickstart，所以看來我只能在這個環境生一個出來，但不知道我生出一個範例出來之後，會不會又被他刁難？
- 在官方 github 上面，有「Firestore」套件的 quickstart 範例的語言（或是環境）是：iOS、Android、JavaScript，所以我有在想，他是不是要我去 try 這三個語言（或是環境）的 quickstart？但如果這三個語言（或是環境）是正常的，我在 Java 這裡就是不正常的，這樣有解決我的問題嗎？其實我不太懂。
接下來的方向是這樣的：
- 我會用官方的 java quickstart 去長出一支程式，而且是參考 iOS、Android、JavaScript 這三個 quickstart 寫出來的，然後再來跟這個 Support 耗。
- 看起來時間會拖的很長，但服務沒辦法這樣時好時壞，我應該會用 JavaScript（嚴格來講應該是要放到 Node.js 環境），先寫一個服務出來頂著。
- 我已經把相同的問題，也丟一份給我們在台灣的代理商了（他們也有 Support），看看接下來會有什麼樣的反應。
這篇文會持續更新到這件事情有結果。
20220430 更新
這週比較忙，還沒時間去幫 Firebase 把官方的 java quickstart 補上 Firestore 的範例，所以毫不意外的 Support 就把這個 case 給關閉了（因為我超過 3 天沒有回覆他），這是意料中的事情，等我先把 Node.js 版本寫出來，解決線上的問題之後，再來慢慢跟 Firebase 原廠 Support 耗。
上次也有提到，我同樣的把問題丟了一份給台灣的代理商，雖然本來就沒有什麼期待，但也稍微記錄一下這個過程：
- 20220422 開單，並且提供相關資訊。
- 20220422 回覆，要求把 Support 帳號加入到專案中方便檢視問題。
- 20220426 09:47 因為我發現 20220422 的信我沒看到，馬上依照要求進行加入帳號工作，並且再一次提供 Support 需要的資訊。
- 20220426 10:38 Support 回信（回信速度很快）如下：
1. 請問您最近在使用上有什麼異動嗎 [1] ？如果並未有過於頻繁的 update，請問依然會回傳錯誤嗎？
2. 我明白您會在 listen 後的 1.5 至 2 小時之間得到錯誤，請問目前依然有此現象出現？每一次 listen 都會出現此錯誤嗎？可否請您提供最近一次出現的時間點給我們。
開始寫作文了。如果使用上有異動，我們自己會去想辦法排除問題啊，誰願意在這裡跟 Support 寫作文呢？然後，「你明白」的意思是什麼呢？我連最小化的應用程式都寄給你參考了，這個程式只要一掛上去 1.5 到 2 個小時，一定會出現那個錯誤，然後你還要問我現在還有沒有這個現象出現？（然後「有沒有這個現象出現」這段話有沒有贅詞啊？）
- 20220429 09:00 我把程式再一次啟動，然後 10:00 就出現錯誤了；而且那個時間點「沒有過於頻繁的異動」，因為完全是沒有任何事件進來的。
把時間點跟錯誤再一次的寄出去給台灣代理商 Support，然後就沒有消息了，5/1 勞動節放假去了；期待下回分曉。
Support Engineer 應該要改名叫做 Support Writer 才對
因為他們只要很會寫文章讓客戶知難而退，而不需要真的用技術解決客戶的問題。
20220507 更新
透過台灣代理商 Support，終於可以跳過那個無效的 Google Support 窗口了，目前得到的回覆是，他們發現一個在 2021 年底發現的問題，最近又發生了：
https://github.com/googleapis/java-firestore/issues/822
目前看起來的狀況是，Java SDK 的 8.1.0 版本，在最近發生了「包錯版本」的問題：
it seems like the latest Admin SDK (8.1.0) is not using the latest BOM version for the GCP Firestore Java SDK (25.2.0) I will engage the Firebase team to look into this.
所以 Google Support 建議我們在他們解決這個問題之前，可以先自己嘗試著使用 Firestore 25.2.0 版本，請參閱：https://cloud.google.com/firestore/docs/create-database-server-client-library#add_the_server_client_library_to_your_app
還好沒有傻傻的去寫 Firestore Java quick-start。
20220530 更新
這件事情目前暫時被擺著了：https://github.com/firebase/firebase-admin-java/pull/670 所以在 firebase 這邊真正解決問題之前，大概也只能等了，因為要自己去調整那個 dependency 的風險實在是有點高啊…
20220704 更新
好一段時間沒有追這件事情的進度，目前看來在 2022/6/16 的 9.0.0 版本已經修正這個問題，實測已經沒有問題。
Add comment