How to handle asynchronous queue errors?

This is it, we have made a public account tool. User group A has the ability to send template messages in groups, and user group B can receive template messages.

After user A fills in the content on the page and submits it, because it is sent in bulk, it may take a very long time, so we implement asynchronous processing and push all the user's messages into a queue. If the push is successful, it will be returned to the user. A is successful. User A's front-end operation is over.

After that, the background will scan the queue every period of time. If there is data in the queue, mass push will be performed.

Now there is such a problem. Uncertain factors begin to appear on the official account (sometimes api changes, sometimes server 50X errors), which causes queue push on my side to begin to fail. Fortunately, network timeouts or temporary errors can be solved with scheduled retries.

But if the server API is replaced like this, our push will fail 100%, and user group B will never receive the message. However, this error will not be seen by user A, who will think that the message was sent successfully. (Because it has been changed to asynchronous, the push ends when it is queued, and you cannot keep staring at this big push list. It may take a very long time)

So I would like to ask if there is any design solution that can make user A aware that there is a problem with the official account server when there is a problem with the official account api server.

I have considered exposing the status of the push list to user A. User A can see the status of the push by himself. However, it doesn't feel intuitive, and user A may not look at this list.

Reply content:

This is it, we have made a public account tool. User group A has the ability to send template messages in groups, and user group B can receive template messages.

After user A fills in the content on the page and submits it, because it is sent in bulk, it may take a very long time, so we implement asynchronous processing and push all the user's messages into a queue. If the push is successful, it will be returned to the user. A is successful. User A's front-end operation is over.

After that, the background will scan the queue every period of time. If there is data in the queue, mass push will be performed.

Now there is such a problem. Uncertain factors begin to appear on the official account (sometimes api changes, sometimes server 50X errors), which causes queue push on my side to begin to fail. Fortunately, network timeouts or temporary errors can be solved with scheduled retries.

But if the server API is replaced like this, our push will fail 100%, and user group B will never receive the message. However, this error will not be seen by user A, who will think that the message was sent successfully. (Because it has been changed to asynchronous, the push ends when it is queued, and you cannot keep staring at this big push list. It may take a very long time)

So I would like to ask if there is any design solution that can make user A aware that there is a problem with the official account server when there is a problem with the official account api server.

I have considered exposing the status of the push list to user A. User A can see the status of the push by himself. However, it doesn't feel intuitive, and user A may not look at this list.

Isn’t this solution unreasonable? Even if user A gets the exception information, you are still the one who handles the problem. What’s the point of giving him an error? Why do I think you should solve the problem of the server api first? The key is

Write error logs.