How to handle asynchronous queue errors?

In this case, we developed A public account tool. User Group A has the ability to send mass template messages, and User Group B receives template messages. After User A fills in the content on the page and submits it, it may take A very long time because it is A mass task, so we make asynchronous processing to put all the user messages pus... in this case, we developed A public account tool. User Group A has the ability to send mass template messages, and User Group B receives template messages.

After User A fills in the content on the page and submits it, it may take A very long time because it is A mass task, so we make asynchronous processing and push all user messages to A queue, if the push operation is successful, user A is returned. User A's frontend operations are complete.

Then, the backend scans the queue every time. if there is data in the queue, the group push is executed.

Now there is such a problem that the public account is beginning to have uncertainties (sometimes api changes, sometimes server 50X errors), leading to the failure of queue push on my side. For example, if the network times out or a temporary error occurs, you can use timed retry to solve the problem.

However, if the server api changes, the push will fail 100%, and User Group B will never receive the message. However, this error cannot be seen in user, the message will be sent successfully (because it is changed to asynchronous mode, the push to the queue ends, and you cannot keep staring at this big push list for a long time)

Therefore, I would like to ask if there is any design scheme that can cause problems with the public account api server. User A can perceive A problem with the public account server.

You have considered exposing the push list status to user A, and user A can view the push status. However, it is not intuitive. user A may not go to the list.

Reply content:

In this case, we developed A public account tool. User Group A has the ability to send mass template messages, and User Group B receives template messages.

After User A fills in the content on the page and submits it, it may take A very long time because it is A mass task, so we make asynchronous processing and push all user messages to A queue, if the push operation is successful, user A is returned. User A's frontend operations are complete.

Then, the backend scans the queue every time. if there is data in the queue, the group push is executed.

Now there is such a problem that the public account is beginning to have uncertainties (sometimes api changes, sometimes server 50X errors), leading to the failure of queue push on my side. For example, if the network times out or a temporary error occurs, you can use timed retry to solve the problem.

However, if the server api changes, the push will fail 100%, and User Group B will never receive the message. However, this error cannot be seen in user, the message will be sent successfully (because it is changed to asynchronous mode, the push to the queue ends, and you cannot keep staring at this big push list for a long time)

Therefore, I would like to ask if there is any design scheme that can cause problems with the public account api server. User A can perceive A problem with the public account server.

You have considered exposing the push list status to user A, and user A can view the push status. However, it is not intuitive. user A may not go to the list.

This solution is not very reasonable. even if user A obtains the exception information, you can handle the problem yourself. what is the significance of giving him an error, how do I think it is critical that you solve the server api problems first?

Write Error logs.