며칠 전 디스코스를 마지막으로 업데이트한 이후, 답변 이메일이 더 이상 작동하지 않는 것 같습니다. 이메일이 수신되지 않아 토론도 업데이트되지 않고, 관찰 중인 카테고리에 대한 발송 이메일도 제대로 작동하지 않아 65개 중 5개만 전송되고 있습니다.
최근 이메일 관련 문제를 겪고 계신 분이 더 계신가요?
불행히도 3.4.0.beta4-dev에서도 동일한 문제가 발생합니다. app.yml 파일 재평가부터 메일 DNS 설정 확인까지 모든 것을 시도해 보았습니다. 아이러니하게도 터미널에서는 Discourse 도커 컨테이너 내에서 wasm을 사용하여 SMTP로 메일을 전송할 수 있었습니다. 이는 어딘가에 설정 버그가 있는 것으로 보입니다. 게시글, 뉴스레터, 비밀번호 재설정 등 이메일을 수신할 수 없는 모든 등록 사용자에게 큰 문제가 됩니다. 550 ERR 메시지는 새로운 업데이트 이후로 계속되고 있습니다. 이제 이 버그가 해결되기를 바라며 v3.4.0.beta2로 롤백하는 것이 해결책이 되기를 기원하고 있습니다.
나만 그런 게 아니어서 다행이에요. 개발자분께서 이 문제를 최대한 빨리 수정해 주시길 바랍니다. 롤백하는 방법을 전혀 모르겠네요.
설치된 버전
3.4.0.beta4-dev
58f75ed205
동시에 PostgreSQL 데이터베이스가 13에서 15로 업데이트되었습니다.
포스트그레SQL 업데이트가 GUI 설정 구성을 망가뜨린 것 같아서 정확히는 모르겠는데, 폴링용 POP3 서버 정보를 추가해도 app.yml 디스코urs 설정 파일에 아무런 변경 사항이 반영되지 않는 걸 확인했거든요… 정말 이상합니다. 롤백은 약간 까다로운데, git 태그로 들어가서 버전별로 전체 앱을 다시 빌드해야 하거든요. 이 작업에 ChatGPT를 활용하면 문제 해결에 도움이 될 수 있습니다.
버전을 되돌려서 해결하셨나요?
개발팀이 조만간 이 문제에 대응해서 전방 호환성 있는 수정을 내놓길 바랍니다.
docker에서 git checkout v3.4.0.beta2를 시도했지만, app.yml 파일도 지정했음에도 불구하고 롤백에 여러 번 실패했습니다. 그래서 곧 나올 beta5에서 이 550 오류 버그를 수정할 수 있도록 Discourse 측에 담당자가 있는지 확인해 볼 예정입니다.
어디서 이 오류를 보고 계신가요? 저는 이메일 관련해서 큰 문제가 있지만, 550 err가 어디서 나타나는지 확인하는 방법을 모르겠습니다. 감사합니다.
GUI를 통해 이메일 로그에서 오류를 확인하지 못했는데, 답장이 수신되지 않고, 65명에게 발송되어야 하는 이메일이 일부 개인에게만 전송되고 있습니다.
/logs에서 이것을 확인합니다:
팀원들을 @멘션으로 호출하지 마세요.
유료 Discourse 고객인 경우 team@discourse.org로 연락하시면 우선 지원 서비스를 받을 수 있으며, 그렇지 않은 경우 최선의 노력(best effort)으로 지원됩니다.
버그를 보고할 때 사용 중인 메일 제공업체를 명시해 주세요. Discourse에서 흔히 사용되는 메일 제공업체에서 문제가 발생한 것일 수도 있습니다. 정확히는 알 수 없습니다.
정말 죄송합니다. 몰랐습니다. 다시는 그러지 않을게요. 멘션에 대해 알려주셔서 감사합니다.
저는 Brevo를 사용하지만, 일부 이메일은 정상적으로 전송되는 것으로 보아 Brevo와 관련이 없다고 생각합니다.
답장은 Gmail을 통해 오고 있지만, 이건 항상 잘 작동해 왔습니다.
다른 답변자분도 같은 문제를 겪고 계시기에, 어떤 것을 사용 중인지 알려주시면 좋겠습니다.
서버 로그 및 보고서 아래에 있습니다. 테스트 이메일을 보내면 ‘건너뜀’ 탭에 550 메일 오류가 반환됩니다. 개발자로부터 아직 아무런 소식이 없습니다. Postgres 15 업데이트와 함께, app.yml에서 통신이 필요한 경우 설정이 데이터베이스에 전달되어 실행되지 않을 수도 있다고 생각합니다.
테스트 이메일은 오류 없이 정상적으로 전송됩니다. 해당 테스트 이메일은 Brevo를 통해 발송됩니다.
제가 겪는 문제는 감시 중인 카테고리 이메일이 일부 사용자에게만 발송된다는 점입니다. 누락된 이메일은 건너뛴(skipped) 상태로 표시되지 않으며, 대부분의 사용자에게는 이메일이 아예 발송되지 않습니다.
두 번째 문제는 회신(Reply) 이메일이 시스템에 전혀 반영되지 않는다는 것입니다.
이러한 문제는 최근 업그레이드 이후에 발생하기 시작했습니다.
저는 Ubuntu 22.04를 사용 중이며, 최근 컨테이너 업그레이드도 있었습니다. 하지만 discourse를 업데이트한 후에야 이메일 문제를 알게 되었어요. 물론 이 업데이트로 Postgres도 함께 업그레이드되었죠.
Phil님은 어떤 운영체제를 사용 중이신가요?
이 메시지가 프로덕션 로그에 자주 나타납니다:
Email can not be processed: Email::Receiver::EmptyEmailError
tail -1000 production.log-20250202 | grep ‘Email::Receiver::EmptyEmailError’ | wc -l
291
이 주제(토픽)는 보지만 해결 방법을 이해하지 못하겠습니다. 혹시 설명해 주실 수 있는 분 계신가요? 예를 들어 받은 편지함(inbox)이 어디에 있는지요. 내 계정에서 메시지를 두 번 클릭하면 받은 편지함을 볼 수 있고 메시지를 삭제할 수는 있지만, 그 안의 메시지는 많지 않습니다. 즉, 모든 수신 답장 이메일을 어떻게 확인하는지, 어떤 받은 편지함을 봐야 하는지 등을 알고 싶습니다.
오류를 클릭하면 더 자세한 정보가 표시됩니까? 이메일 한 통의 형식이 이상하거나 잘못되어 해당 이메일을 처리할 작업을 계속 다시 예약하는 상황일 수도 있습니다.
방금 게시한 주제가 65개의 이메일을 생성해야 했는데, 실제로는 '보낸 편지함’에 5개만 생성되었고, 건너뜀 항목도 없으며 기타 상태도 없습니다. 오류나 경고 메시지도 표시되지 않았습니다.
어제 /logs에서 하나의 오류와 하나의 경고를 확인했는데, 제 이메일 문제와 관련이 있는지 모르겠습니다:
Message (552 copies reported)
Job exception: Net::ReadTimeout
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:229:in `rbuf_fill'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:199:in `readuntil'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:377:in `each_message_chunk'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:958:in `block in retr'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:1016:in `critical'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:956:in `retr'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:810:in `pop'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:47:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:46:in `block in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:45:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'
Message (694 copies reported)
Email can not be processed: Email::Receiver::EmptyEmailError
Backtrace
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `block in warn'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:130:in `warn'
/var/www/discourse/lib/email/processor.rb:183:in `log_email_process_failure'
/var/www/discourse/lib/email/processor.rb:29:in `rescue in process!'
/var/www/discourse/lib/email/processor.rb:16:in `process!'
/var/www/discourse/lib/email/processor.rb:13:in `process!'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:29:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:49:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:46:in `block in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:45:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:316:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/app/jobs/base.rb:303:in `block in perform'
/var/www/discourse/app/jobs/base.rb:299:in `each'
/var/www/discourse/app/jobs/base.rb:299:in `perform'
/var/www/discourse/app/jobs/base.rb:379:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:137:in `process_queue'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:77:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:63:in `block (2 levels) in ensure_worker_threads'
65개의 이메일이 생성되어야 한다는 사실을 어떻게 아시나요?
Watched 카테고리가 설정된 사용자가 누구인지 정확히 알고 있으며, 해당 카테고리는 Watched 카테고리로 설정되어 있고, 알림을 무음 처리한 사용자는 없습니다. 업데이트 이전과 마찬가지로 반드시 65개의 이메일이 전송되어야 합니다.
오늘 늦은 시각에 3.4.0.beta4-dev에서 새 버전으로 업데이트를 진행하여 차이가 있는지 확인해 보겠습니다.
또한 VM을 재부팅할 계획입니다. 이는 데이터베이스를 정상적으로 재시작하는 효과가 있을 것으로 생각되며, 참고로 3.4.0.beta4-dev로 업데이트할 당시 문서대로 데이터베이스가 올바르게 설치되었습니다.
이미 언급한 Ubuntu 22.04 OS의 containerd 업데이트 외에 다른 문제는 없을 것으로 생각됩니다. 다만, 지난주 후반에 수행한 유일한 변경 사항은 CakeDay 플러그인을 설치한 것입니다.