是這樣的，我們做了一個公眾號工具，用戶群A具有群發模板訊息的能力，用戶群B是接收模板訊息。
用戶A在頁面上填寫內容之後提交之後，由於是群發的，時間可能會非常長，所以我們做成了異步處理，把用戶的消息都push到一個隊列之中，push成功了就返回給用戶A成功。使用者A前端操作就結束了。
之後後台每一段時間就會掃描一次佇列，如果佇列中有數據，就執行群發推送。
現在出了這樣一個問題，公眾號那邊開始出現不確定因素（有時是api變更，有時是伺服器50X錯誤），導致我這邊佇列推送開始出現失敗的情況。像是網路逾時或臨時性錯誤還好，可以用定時重試的方法來解決這個問題。
但如果是伺服器api更換這種，我們這邊推送就會100%失敗，用戶群B就永遠也收不到消息，然而這種錯誤在用戶A這邊是看不到的，會以為發送成功（因為改成異步了嘛，push到隊列中就結束了，也不能一直盯著這個大推送列表看，時間可能會非常久）
所以想問有沒有什麼設計方案能讓公眾號api伺服器出問題時，用戶A這側能感知到是公眾號伺服器出了問題。
自己考慮過可以將推送列表狀態暴露給用戶A看，用戶A能自己看到推送的狀態。然而感覺並不直觀，用戶A可能不會去看這個清單。
是這樣的，我們做了一個公眾號工具，用戶群A具有群發模板訊息的能力，用戶群B是接收模板訊息。
用戶A在頁面上填寫內容之後提交之後，由於是群發的，時間可能會非常長，所以我們做成了異步處理，把用戶的消息都push到一個隊列之中，push成功了就返回給用戶A成功。使用者A前端操作就結束了。
之後後台每一段時間就會掃描一次佇列，如果佇列中有數據，就執行群發推送。
現在出了這樣一個問題，公眾號那邊開始出現不確定因素（有時是api變更，有時是伺服器50X錯誤），導致我這邊佇列推送開始出現失敗的情況。像網路逾時或臨時性錯誤還好，可以用定時重試的方法來解決這個問題。
但如果是伺服器api更換這種，我們這邊推送就會100%失敗，用戶群B就永遠也收不到消息，然而這種錯誤在用戶A這邊是看不到的，會以為發送成功（因為改成異步了嘛，push到隊列中就結束了，也不能一直盯著這個大推送列表看，時間可能會非常久）
所以想問有沒有什麼設計方案能讓公眾號api伺服器出問題時，用戶A這側能感知到是公眾號伺服器出了問題。
自己考慮過可以將推送列表狀態暴露給用戶A看，用戶A能自己看到推送的狀態。然而感覺並不直觀，用戶A可能不會去看這個清單。
這個解決方法是不是不太合理，用戶A就算獲取到異常信息，處理問題的還是你們自己，你給他個錯誤的意義何在，我怎麼覺得你應該先解決服務器api的問題是關鍵
寫錯誤日誌。
