是这样的，我们做了一个公众号工具，用户群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的问题是关键
写错误日志。
