그래서 공개 계정 도구를 만들었습니다. 사용자 그룹 A는 그룹별로 템플릿 메시지를 보낼 수 있고, 사용자 그룹 B는 템플릿 메시지를 받을 수 있습니다.
사용자 A가 페이지 내용을 작성하고 제출한 후 대량으로 전송되기 때문에 시간이 매우 오래 걸릴 수 있으므로 비동기 처리를 구현하여 사용자의 모든 메시지를 대기열에 푸시하고 반환합니다. 푸시가 성공한 후 사용자 A. 사용자 A의 프런트엔드 작업이 끝났습니다.
이후 백그라운드는 일정 시간마다 큐를 스캔합니다. 큐에 데이터가 있으면 대량 푸시가 수행됩니다.
이제 이런 문제가 공식 계정에 나타나기 시작하는데(때때로 API 변경, 때로는 서버 50X 오류), 이로 인해 내 쪽의 대기열 푸시가 실패하기 시작합니다. 다행히 네트워크 시간 초과나 일시적인 오류는 예약된 재시도를 통해 해결할 수 있습니다.
하지만 서버 API를 이렇게 교체하면 푸시가 100% 실패하고 사용자 그룹 B는 메시지를 받지 못합니다. 하지만 이 오류는 사용자 A가 볼 수 없습니다. 비동기식으로 변경되었으며 대기열에 추가되면 푸시가 종료되며 이 큰 푸시 목록을 계속 쳐다볼 수 없습니다. 시간이 매우 오래 걸릴 수 있습니다.)
그래서 공식계정 api 서버에 문제가 생겼을 때, A 사용자가 공식계정 서버에도 문제가 있다는 것을 인지하게 할 수 있는 디자인 솔루션이 있는지 여쭤보고 싶습니다.
사용자 A에게 푸시 목록의 상태를 노출하는 것을 고려했습니다. 사용자 A는 푸시 상태를 직접 볼 수 있습니다. 하지만 직관적으로 느껴지지 않으며, 사용자 A는 이 목록을 보지 않을 수도 있습니다.
그래서 공개 계정 도구를 만들었습니다. 사용자 그룹 A는 그룹별로 템플릿 메시지를 보낼 수 있고, 사용자 그룹 B는 템플릿 메시지를 받을 수 있습니다.
사용자 A가 페이지 내용을 작성하고 제출한 후 대량으로 전송되기 때문에 시간이 매우 오래 걸릴 수 있으므로 비동기 처리를 구현하여 사용자의 모든 메시지를 대기열에 푸시하고 반환합니다. 푸시가 성공한 후 사용자 A. 사용자 A의 프런트엔드 작업이 끝났습니다.
이후 백그라운드는 일정 시간마다 큐를 스캔합니다. 큐에 데이터가 있으면 대량 푸시가 수행됩니다.
이제 이런 문제가 공식 계정에 나타나기 시작하는데(때때로 API 변경, 때로는 서버 50X 오류), 이로 인해 내 쪽의 대기열 푸시가 실패하기 시작합니다. 다행히 네트워크 시간 초과나 일시적인 오류는 예약된 재시도를 통해 해결할 수 있습니다.
하지만 서버 API를 이렇게 교체하면 푸시가 100% 실패하고 사용자 그룹 B는 메시지를 받지 못합니다. 하지만 이 오류는 사용자 A가 볼 수 없습니다. 비동기식으로 변경되었으며 대기열에 추가되면 푸시가 종료되며 이 큰 푸시 목록을 계속 쳐다볼 수 없습니다. 시간이 매우 오래 걸릴 수 있습니다.)
그래서 공식계정 api 서버에 문제가 생겼을 때, A 사용자가 공식계정 서버에도 문제가 있다는 것을 인지하게 할 수 있는 디자인 솔루션이 있는지 여쭤보고 싶습니다.
사용자 A에게 푸시 목록의 상태를 노출하는 것을 고려했습니다. 사용자 A는 푸시 상태를 직접 볼 수 있습니다. 하지만 직관적으로 느껴지지 않으며, 사용자 A는 이 목록을 보지 않을 수도 있습니다.
이 해결 방법은 무리한 것 아닌가요? 사용자 A가 예외 정보를 받아도 문제를 처리하는 사람은 바로 당신입니다. 왜 그에게 오류를 주어야 한다고 생각합니까? API 먼저?
오류 로그를 작성합니다.