모든 조건을 충족해도 사용자가 Digest/Activity Summary 이메일을 받지 못함 (Discourse 3.6)

지원
,
1

현재 Discourse 3.6을 사용 중인데, 다이제스트 이메일을 받아야 할 일부 사용자에게 이메일이 도착하지 않는 문제를 겪고 있습니다.

해당 사용자를 확인한 결과 다음과 같은 사항이 확인되었습니다:

  • enable_digest_emails가 true로 설정되어 있습니다.

  • 사용자는 다이제스트가 트리거될 만큼 충분히 비활성 상태였습니다.

  • 이메일 주소가 유효하며 확인이 완료되었습니다.

  • 메일 제공업체로부터 바운스(bounce) 또는 억제(suppression)가 발생하지 않았습니다.

  • 다른 이메일(알림 등)은 정상적으로 전송됩니다.

  • 관리자 → 이메일 → 전송 로그(Admin → Emails → Sent)에 다이제스트 이메일 기록이 없습니다.

  • 관리자 → 이메일 → 다이제스트 테스트(Admin → Emails → Digest Test)를 사용하면 시스템이 “네, 다이제스트가 전송되어야 합니다”라고 올바르게 표시하지만, 실제로는 아무것도 전송되거나 기록되지 않습니다.

Sidekiq나 프로덕션 로그에 관련 오류가 표시되지 않습니다.

관리자 UI에서 모든 설정 및 자격 요건 확인이 사용자에게 다이제스트가 전송되어야 한다고 나타내더라도, 3.6에서 다이제스트 이메일이 조용히 실패하는 현상을 경험하신 분 계신가요?

2

사용자 설정의 이메일 탭에서 사용자 설정을 확인해 보셨나요?

3

네, 여기가 해당 설정이고, 여기는 전송해야 한다고 표시되는 다이제스트 렌더링입니다.

IMG_7947
IMG_79471290×2796 293 KB

IMG_7946
IMG_79461290×2796 243 KB

4

업데이트 / 재현 단계 (Discourse 3.6)

Rails 콘솔을 사용하여 작업(job) 레벨에서 어떤 일이 일어나고 있는지 확인하기 위해 명시적인 재현 테스트를 수행했습니다. 영향받는 사용자의 경우 다음 내용을 확인할 수 있습니다:

site: hvac

now: 2025-10-15 17:23:01 UTC

disable_emails: “no”

disable_digest_emails: false

default_email_digest_frequency_minutes: 10080

ENV_DISABLE_EMAILS: nil

perform_deliveries: nil

smtp_address: “smtp.netcorecloud.net”

smtp_port: 587

– USER –

id: 42122

username: XXXXXXXXXX

active: true

suspended: false

email_digests: true

digest_after_minutes: 10080

eligible_by_time: true

– LAST 15 EMAIL LOGS –

2025-10-01 | type=digest | bounced=false

2025-09-22 | type=digest | bounced=false

perform_deliveries_now: true

그런 다음 다이제스트를 수동으로 강제 빌드했을 때, Discourse는 다이제스트를 빌드하는 것으로 인식하지만 다음을 반환합니다:

mail = UserNotifications.digest(u)

=> Built digest mail: subject=nil bytes=50

즉, Discourse는 다이제스트를 빌드하는 것으로 생각하지만 실제로는 비어 있습니다(subject=nil) — 따라서 작업이 실행될 때 조용히 건너뛰어집니다. EmailLog 항목이 생성되지 않으며 아무것도 전송되지 않습니다.

이로써 다음 사항이 확인되었습니다:

  • 작업이 성공적으로 큐에 추가됩니다

  • SMTP 및 전송(deliveries)이 활성화되어 있습니다

  • 메일러가 빈 다이제스트를 반환하기 때문에 다이제스트 작업은 오류 없이 종료됩니다

다음과 같이 작업을 인라인으로 실행하면:

Jobs::UserEmail.new.execute(“type” => “digest”, “user_id” => u.id”)

동일한 결과가 나타납니다 — 새로운 EmailLog 행이 생성되지 않습니다.

가능한 원인:

다이제스트가 “빈 다이제스트” 조건으로 인해 건너뛰어지는 것 같습니다 — 아마도 Discourse 3.6에서 포함될 콘텐츠를 평가하는 방식이 변경되었을 수 있습니다. Admin → Emails → Digest Test 뷰에서는 다이제스트가 올바르게 렌더링되지만, 백그라운드 작업에는 포함할 것이 아무것도 보이지 않습니다.

요약:

:white_check_mark: 대상 사용자

:white_check_mark: 활성 이메일 + 유효한 SMTP

:white_check_mark: Admin Digest Test가 올바르게 렌더링됨

:prohibited: 백그라운드 다이제스트 작업이 조용히 건너뛰어짐 (빈 다이제스트)

:prohibited: EmailLog 또는 전송 시도가 기록되지 않음

팀의 확인을 부탁드립니다 — 3.6에서 UserNotifications.digest가 콘텐츠를 수집하는 방식에 회귀(regression)가 있을 수 있나요?

5

여기서 조금 더 작업을 해본 결과, 실제로 활동 요약이 안정적으로 수신되는 사용자(전체 4,000명 중)가 소수 있다는 사실을 발견했습니다.

요약을 받는 사용자 한 명과 받지 않는 사용자 한 명의 설정을 비교해 보았지만, 두 사용자 간에 어떤 차이도 보이지 않았습니다.

===== xxxxx (ID: 4149) =====
활성: true, 정지됨: false, 무음 처리됨: false
이메일 확인됨: false
다이제스트 활성화: true
다이제스트 주기: 10080분
마지막 접속: 2025-03-24 20:58:55 UTC
마지막 이메일 발송: 2025-10-16 17:07:53 UTC
무음 처리된 카테고리:
사용자 통계 다이제스트 시도: 2025-10-16 17:07:53 UTC
총 발송된 이메일: 16
===== xxxxxxx (ID: 42206) =====
활성: true, 정지됨: false, 무음 처리됨: false
이메일 확인됨: false
다이제스트 활성화: true
다이제스트 주기: 10080분
마지막 접속: 2025-09-14 15:52:54 UTC
마지막 이메일 발송: 2025-10-01 23:30:33 UTC
무음 처리된 카테고리:
사용자 통계 다이제스트 시도: 2025-10-16 17:32:34 UTC
총 발송된 이메일: 2

물론 다른 설정들도 있겠지만, 어쨌든 이 비교는 흥미로웠습니다.

7

Rails 명령어를 실행하여 실제로 기한이 지난 다이제스트/활동 요약이 얼마나 되는지 확인할 수 있는 방법을 아시는 분 계신가요? 기본적으로 시스템이 설계된 대로 요약을 정상적으로 전송하고 있는지 확인하는 헬스 체크입니다.

8

아래의 Rails 콘솔 쿼리를 실행해 보세요. 이메일 다이제스트를 활성화한 활성 사용자 중 다음 다이제스트 이메일 발송 대상에 해당하는 사용자를 조회합니다.

User.joins(:user_option)
  .where("user_options.email_digests = ?", true)
  .where("users.suspended_at IS NULL")
  .where("COALESCE(users.last_emailed_at, users.created_at) < (NOW() - INTERVAL '1 minute' * user_options.digest_after_minutes)")
  .count
9

Suppress digest email after days 설정 때문에 사용자가 해당 기간 동안 방문하지 않아 요약이 건너뛰어지는 것이 가능한가요?

10

@jahan_gagan 유용한 정보네요. 하지만 그건 누가 다이제스트/활동 요약 메일을 받을지 알려줄 뿐, 활동 요약을 받지 않은 사람은 누구인지 알려주지는 않아요. 이해되시나요? 문제는 다이제스트를 받아야 할 사람이 실제로 받지 못한 경우를 어떻게 확인할 수 있는지가 핵심입니다.

11

@Moin 현재 0으로 설정되어 있습니다. 따라서 이것이 원인이 되지는 않아야 합니다.

12

0이 해당 기능을 비활성화하는지 확신하나요? 대신 큰 숫자를 사용해 보셨나요?

13

@Moin 감사합니다 - 아니, 확신이 없습니다. 3000으로 변경해 보았지만 다이제스트가 전송되는 데에는 변화가 없었습니다. 주간 빈도로 설정한 지 2주가 넘었지만, 여전히 수백 건의 항목이 전송되지 않은 상태로 남아 있습니다.

14

좋아요, 현재 누가 대상자인지 확인하기 위한 테스트입니다:

Screenshot 2025-10-23 at 1.19.51 PM
Screenshot 2025-10-23 at 1.19.51 PM947×298 70.5 KB

지금 강제 전송을 시도했는데, 아무것도 전송되지 않았습니다…

Screenshot 2025-10-23 at 1.21.37 PM
Screenshot 2025-10-23 at 1.21.37 PM872×347 67.5 KB

디제스트를 받지 않는 샘플 사용자를 하나 골라서 관리자 인터페이스를 확인해 보니, 해당 사용자는 완전히 대상 조건에 맞는 것으로 보입니다…

Screenshot 2025-10-23 at 1.24.25 PM
Screenshot 2025-10-23 at 1.24.25 PM923×703 44.6 KB

16

음, 다른 아이디어가 없어서 관리자 설정을 통해 모든 사용자의 다이제스트 발송 주기를 일 단위로, 즉 1440분으로 변경했습니다.

그런데 갑자기 다이제스트가 모두 발송되었어요…

이유를 아는 사람이 있을까요? 주간 주기로도 대상에 해당되는 사용자들임을 확인할 수 있으므로, 주기 변경은 아무런 영향을 주지 않아야 할 것 같은데 말이죠.

17

아, 너무 일찍 말했네요. 주파수 변경이 한 사용자 그룹(한 사이트)에는 효과가 있었지만, 다른 곳에는 아무런 변화가 없었습니다. 미스터리가 계속되고 있네요…

18

위에서 링크한 쿼리의 마지막 요구 사항 중 하나 때문일 것 같습니다.

사용자가 실존하는지, 활성화되어 있는지, 스테이지 상태가 아닌지, 정지되지 않았는지 확인하고, 다이제스트를 비활성화하지 않았는지, 빈도가 0보다 큰지 확인한 후, 주요 이메일이 있고 바운스 점수가 정상적인 경우, 다음과 같은 시간 기반 체크가 있습니다:

마지막 확인 시각이 digest_after_minutes 이전보다 더 오래전이어야 합니다
마지막 확인 시각이 suppress_digest_email_after_days 범위 내에 있어야 합니다
사용자가 다이제스트를 받아야 하는지 마지막 확인이 digest_after_minutes 전에 이루어졌어야 합니다.

마지막 항목이 원인이 아닐까 생각합니다. 만약 Discourse가 어제 다이제스트 전송을 시도했고 digest_after_minutes가 1주라면, 1주가 지나기까지는 다시 시도하지 않습니다. 이 값을 줄이면 다음 시도가 더 일찍 이루어집니다.

19

@Jacob_Peebles 이 문제를 꽤 오랫동안 고심하고 계신 것 같습니다! 3월에 올라온 Digest Emails Not Sending to All Users – Need Help Debugging 이 게시물이 동일한 문제에 관한 것인 것 같은데, 맞나요?

Moin의 최신 게시물이 도움이 되었나요? 도움이 되었다면 알려 주시면 이 주제를 마무리할 수 있도록 하겠습니다.

22

@Jacob_Peebles 이 주제에 대해 무엇을 하고 싶으신가요? 닫아야 할까요, 아니면 이 사안에 대해 새롭게 발견한 정보가 있으신가요?