person wearing red head gear

與 Firebase Support 搏鬥記事


有一組 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。

Add comment

Most discussed