# 60일 이상 승인 대기 중인 모든 사용자에게 오류 및 잘못된 이메일 알림을 보내는 회귀 문제
**URL:** https://meta.discourse.org/t/regression-causing-erroneous-incorrect-email-notifications-sent-to-all-users-in-the-approval-queue-for-over-60-days/180782
**Category:** Bug
**Created:** [2월 22, 2021, 7:03오후 UTC](https://meta.discourse.org/t/regression-causing-erroneous-incorrect-email-notifications-sent-to-all-users-in-the-approval-queue-for-over-60-days/180782 "2021-02-22T19:03:33Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2월 22, 2021, 7:03오후 UTC](https://meta.discourse.org/t/regression-causing-erroneous-incorrect-email-notifications-sent-to-all-users-in-the-approval-queue-for-over-60-days/180782/1 "2021-02-22T19:03:34Z")
Discourse에서는 가입 시 사용자 계정이 생성되지만, 계정이 활성화되기 전에 스태프의 승인을 받아야 하는 모드를 지정할 수 있습니다. 이는 구독 기반 사이트에서 흔히 볼 수 있는 방식입니다.
이 기능이 작동하는 방식에는 두 가지 중요한 측면이 있었습니다:
1. 스태프가 계정을 거부할 때 부정적인 알림은 절대 전송되지 않았으며, 스태프가 계정을 승인할 때만 긍정적인 알림이 한 번 전송되었습니다.
2. 검토 대기열에 있는 항목(게시물 또는 계정)은 60일 동안 모더레이터가 해당 검토 대기열 항목에 조치를 취하지 않으면 기본적으로 거부됩니다. 이는 Discourse의 이전 여러 버전에서도 존재해 온 기능으로, 이 경로는 "기본적으로 안전(default safe)"하도록 선택되었습니다.
불행히도, 사용자가 거부된 이유를 알 수 있도록 해주는 [요청된 새 기능](https://github.com/discourse/discourse/commit/06b7c44593fe8299d120a8956b57b4a9b484131e)을 추가할 때, 위에서 언급한 #1과 #2의 조합이 **승인 대기열에 60일 이상 존재했던 _모든_ 사용자에게 개별적인 부정적인 알림을 전송하게 만들 것** 이라는 점을 우리는 인식하지 못했습니다!
해당 이메일 알림은 다음과 같았습니다:
고객의 브랜드 이름 아래 다음과 같은 내용이 담겨 있었습니다.
> {brand}에서 스태프가 고객님의 계정을 거부했습니다.
이 메시지가 너무 많은 “거부된” 계정으로 전송된 것은 호스팅 고객들에게 문제를 일으켰습니다. 이 실수에 대해 깊이 사과드립니다. 이는 전적으로 Discourse 측의 잘못이며, 모든 책임은 우리에게 있습니다.
현재 우리는 고객을 돕기 위해 최선을 다하고 있습니다.
이것이 **우리의 버그** 이며, **매우 혼란스럽고 표현이 부주의한 이메일** 을 많은 고객에게 전송하여 상당한 혼란을 야기하고, 고객이 구독을 취소함으로써 매출 손실로까지 이어졌을 수 있다는 점을 명확히 하고자 합니다. 이 일에 대해 _정말 죄송합니다_. 우리가 할 수 있는 최소한의 일은 **이것이 Discourse의 문제이며, Discourse에서 그 부정적인 이메일을 잘못 전송했다는** 사실을 모든 이에게 알리는 것입니다. 우리는 해당 버그와 그 결과에 대해 전적으로 책임집니다. 만약 그 이메일을 받으셨다면, 그 누구의 잘못도 아닌 오직 우리, 즉 Discourse의 잘못입니다.
우리는 이것이 얼마나 심각한 일인지 잘 알고 있습니다. 우리는 멤버십 제공업체와 영향을 받은 고객들과 긴밀히 협력하여 우리의 행동에 대한 책임을 지고, 이러한 일이 다시 발생하지 않도록 개선책을 마련하고 있습니다.
또한, 우리가 일으킨 문제에 대한 보상으로서 해당 고객의 다음 달 호스팅 비용을 무료로 제공할 예정입니다. 이 오류와 그것이 우리 고객에게 미친 영향에 대해 진심으로 사과드립니다. 우리는 이러한 유형의 문제가 미래에 발생하지 않도록 프로세스를 반드시 재검토하겠습니다.
Jeff Atwood
CEO, Discourse
---
### Author:  [@supermathie](https://meta.discourse.org/u/supermathie)
#### Post date: [2월 22, 2021, 7:33오후 UTC](https://meta.discourse.org/t/regression-causing-erroneous-incorrect-email-notifications-sent-to-all-users-in-the-approval-queue-for-over-60-days/180782/3 "2021-02-22T19:33:30Z")
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [2월 22, 2021, 7:50오후 UTC](https://meta.discourse.org/t/regression-causing-erroneous-incorrect-email-notifications-sent-to-all-users-in-the-approval-queue-for-over-60-days/180782/4 "2021-02-22T19:50:01Z")
문제를 수정하고 재발을 방지하기 위해 다음 조치들을 취했습니다:
>
>
> FIX: add context when user is deleted via auto handle queued reviewable
> FIX: do… not delete email\_log when a user is deleted
이 커밋은 3가지 문제를 동시에 해결한 것입니다. 이 세 가지 문제는 해당 버그의 원인이 되었으며, 근본 원인을 빠르게 파악하는 것을 방해했습니다.
1. 사용자 계정이 삭제될 때 "이메일 로그"가 삭제되지 않도록 했습니다. 삭제된 사용자의 이메일 로그를 보유하고 있었다면, 발송된 모든 거부 이메일을 빠르게 확인할 수 있었을 것입니다.
2. 코드 내에서 사용자를 삭제하는 모든 위치에서 "컨텍스트"가 올바르게 설정되도록 했습니다. 이를 통해 사용자가 어디서, 왜 삭제되었는지를 명확하게 파악할 수 있습니다. 코드에는 컨텍스트가 설정되지 않은 곳이 여러 곳 있어 해당 사용자가 왜 삭제되었는지 알 수 없었고, 코드를 직접 파고들어 원인을 찾아야 했습니다.
3. 실제 버그를 수정하여, 자동 삭제된 검토 대상(reviewable) 사용자에게 더 이상 거부 이메일을 보내지 않도록 했습니다.
이 모든 변경 사항은 테스트와 함께 이루어졌으므로, 회귀(regression)가 발생하지 않을 것이라고 확신합니다.