유령 가입 (이관 후 동일한 계정을 가진 두 명의 사용자)

안녕하세요. 몇 번의 Discourse 업데이트 전부터 문제가 발생했는데, 새로운 사용자가 승인을 기다리고 있다는 알림을 받으면 검토 대기열을 확인해 보았을 때 대기열이 비어 있는 경우가 있습니다.

이 문제는 단 하나의 사용자만 승인을 요청할 때만 발생합니다. 여러 사람이 대기 중이면 대기열에서 한 명을 제외한 모든 사용자를 볼 수 있지만, 항상 한 명은 포함되지 않습니다.

즉, 많은 사용자가 가입하지 못하고 있는 상황입니다.

별도의 스레드에서는 다중 선택(multi-select) 플러그인이 어떻게든 관련되어 대기열 길이에 1을 더하는 원인이 될 수 있다는 제안이 있었습니다.

하지만 전체적으로 볼 때 이는 가능성이 낮아 보입니다. 왜냐하면 어떤 날에는 알림이 트리거되고 어떤 날에는 그렇지 않기 때문에, 무언가가 일어나고 있어야 하기 때문입니다. 또한 이 문제는 플러그인이 설치된 시점에 시작된 것이 아니라 몇 달 후에 시작되었고, 그 시점은 Discourse 업데이트와만 연관 지을 수 있습니다(그 이후로 다른 플러그인이나 변경 사항이 없었기 때문이죠).

혹시 다른 분들도 이런 문제를 경험해 보셨나요? 그리고 해결책은 무엇일까요?

혹시 @jjaffeux 님, 이 플러그인에 적용하신 “FIX: makes value parsing more resilient” 수정 사항이 이 문제와 관련이 있을 수 있을까요?

이 플러그인은 코어 Discourse 기능에만 관련되거나 기반을 두고 있는 건가요? 명확하지가 않습니다.

안녕하세요 - 저도 정확히 모르겠습니다. 둘 다 원인일 수도 있나요?
이 문제는 플러그인이 처음 설치되었을 때부터 생긴 것이 아니라, 몇 번의 코어 업데이트 전부터 시작되었습니다. 플러그인이 원인에 관여한다면, 의도치 않은 상호작용이 있는 것은 아닌지 궁금합니다.

이 플러그인은 필수적이므로, 문제를 계속 겪는지 확인하기 위해 플러그인을 제거하여 테스트할 수 없습니다. 사용자 가입 심사 과정에서 사용자가 이 플러그인이 활성화된 상태에서만 제공할 수 있는 답변(드롭다운 목록에서 선택)에 의존하고 있기 때문입니다.

GitHub - procourse/discourse-multiselect-user-field · GitHub 은 실제로 플러그인이라기보다는 JavaScript만 포함하고 있습니다.

첫 번째 추천으로, "잘못된 상태(bad state)"가 될 때까지 기다린 후 브라우저의 안전 모드(safe mode)를 활성화하여 큐(queue)가 정상적으로 보이는지 확인해 보시는 것이 좋습니다.

안전 모드에서 문제가 없다면, #marketplace에 게시물을 올려 해당 플러그인을 테마 컴포넌트로 변환하고 Discourse의 최신 패턴에 맞게 업데이트하도록 요청하는 것이 좋습니다.

샘, 고마워요.

불행히도 안전 모드에서도 동일한 결과가 나와요. 대기 중인 사용자에 대한 알림이 올 때, 세 가지 사이트 커스터마이징 항목을 모두 비활성화한 상태로 Discourse 안전 모드를 방문해도 검토 대기열에서 여전히 한 명이 누락되어 있어요.

이것은 무엇을 시사하나요?

이 주제에 대해 리뷰 대기열 전문가가 검토해 볼 필요가 있을 수도 있습니다. 이 문제를 표시해 두었으며, 며칠 이내에 누군가 연락을 드릴 것입니다.

문제를 재현하는 정확한 단계는 매우 도움이 될 것입니다.

샘, 감사합니다.

정확한 단계를 파악하기가 매우 어렵습니다. 제가 특별히 이례적인 작업을 한 것인지는 확신이 없으며, 문제가 발생한 시점을 특정 이벤트로 특정할 수도 없습니다.

제 생각에는 주요 원인이 Discourse 업데이트이거나, 3월 14일에 @j.jaffeux 님이 ‘값 파싱을 더 견고하게 만들기 위해’ 다중 선택 플러그인을 업데이트한 것 중 하나일 것입니다.

문제는 새로운 가입이 매우 불규칙하다는 점입니다. 한 주에 한 번도 가입이 없을 수 있어, 원인과 결과 사이에 상당한 시간 차이가 있을 수 있습니다.

크롬의 시크릿 모드를 사용하고 가짜 계정을 만들어 문제를 직접 재현해 볼 수 있나요?

신청서가 대기열에 들어오려면 사용 가능한 이메일 주소를 지정해야 하는 것 같습니다.

테스트 목적으로 이미 사용했던 이메일 주소가 하나도 없습니다 - 모든 이메일 주소에 이미 계정이 있습니다.

Gmail을 사용 중이라면 + 주소 방식을 사용할 수 있습니다. jane+something@gmail.com으로 보낸 메일은 jane@gmail.com으로 전달됩니다.

좋아요, 흥미로웠습니다. 위에서 언급한 대로 제 Gmail 계정을 사용해 보았는데, 다른 브라우저 창에서 Gmail 웹페이지로 이동하여 Discourse에서 생성된 인증 이메일이 도착하기를 기다리는 동안에도, 새로운 가입자가 검토 대기 중이라는 알림이 제 일반 관리자 이메일 주소로 전송되었습니다. (그리고 대기열은 이전처럼 비어 있었습니다.)

제 Gmail 주소를 잘못 입력했기 때문에 Gmail 계정으로 인증 이메일을 받지 못했고, 따라서 인증을 완료하지 못했습니다.

따라서 이것이 우연이 아니라면, 관리자 알림이 너무 앞서 나가는 것일까요? 하지만 그렇다면 왜 모든 알림에서 정확히 한 명만이 대기열에서 누락되는지 설명할 수 없습니다. 아마도 한 지원자의 이메일 인증 실패와 나머지 지원자의 성공이 항상 반복되지는 않을 것이기 때문입니다.

** 수정

이후, 해당 인코그니토 가입 창에서 제 Gmail 주소를 수정하고 인증 이메일을 다시 전송했습니다. 그제서야 Gmail 브라우저 창에 이메일이 도착했습니다. 다른 인코그니토 창에서 인증 URL을 사용하여 인증에 성공적으로 완료했습니다. 이후 관리자 이메일 주소로 추가 알림이 전송되지 않았으므로, 첫 번째 알림이 실제로 이 새로운 가입 시도와 관련이 있었음을 추측할 수밖에 없습니다.

또 다른 브라우저 창을 사용하여 안전 모드에서 사이트에 다시 접속하고 관리자로 로그인한 결과, 여전히 한 명이 검토 대기 중인 동일한 대기열을 확인했습니다. 하지만 이번에는 제 새로운 테스트 계정이 표시되어 승인할 수 있었습니다.

이 모든 것이 문제 해결에 도움이 될까요?

추가로 말씀드리자면, 인코그니토 창을 통해 새로운 가짜 계정을 생성하여 다시 시도해 보았습니다(이번에는 처음부터 정확한 주소를 입력했습니다). 이 시도는 예상대로 정상적으로 작동했고, 일반 브라우저 창에서 이메일로 받은 관리자 알림에 응답했을 때 대기열에 새 사용자가 표시되는 것을 확인했습니다.

이어서 일반 창을 통해 새로운 가입을 진행했고, 알림에도 일반 창으로 응답했습니다(인코그니토 모드나 안전 모드를 전혀 사용하지 않았습니다). 이번에도 모든 것이 정상적으로 작동했습니다. 따라서 해당 문제(또는 두 가지 문제—지원자의 이메일 주소 확인 전에 관리자에게 알림이 전송되는 것과, 미완성 또는 완료된 신청서가 대기열에 표시되지 않는 것)는 첫 번째 시도에서만 발생했던 것으로 보입니다.

다시 한번 말씀드리지만, 이것이 문제를 명확히 하는 데 큰 도움이 될지는 잘 모르겠습니다. 하지만 시스템에 의해 첫 번째 가입이 실패(유령 알림 생성)한 이후, 이후의 가입들은 정상적으로 작동하는 것은 아닐까요? 혹은 가입 활동이 더 이상 없으면 충분한 시간이 지난 후 다시 실패 모드로 복귀하는 것일 수도 있습니다.

Hi @Paul_King

제가 언급하신 커밋과 거의 같은 시점에 추가한 마이그레이션이 이 문제를 일으킨 것 같습니다. 이로 인해 승인되지 않은 일부 사용자가 검토 대기열에 있는 것처럼 보이며, 이상한 알림이 발생하고 있습니다.

데이터 탐색기에서 아래 쿼리를 실행해서 이 추측이 맞는지 확인해 주시겠어요?

SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'User' AND r.status = 1 AND users.approved = FALSE

로만, 안녕하세요.

방금 쿼리를 실행해 보았는데, 제가 제대로 수행했다면(스크린샷 참조) 카운트는 0이었습니다.

다만 현재 제 디스코urs 설치 환경에서도 대기 중인 사용자가 없다고 표시됩니다.
방금 가짜 계정을 하나 더 생성하고 이메일 인증을 완료했는데, 아직 관리자 이메일 계정으로 어떤 알림도 전송되지 않았습니다. 다시 관리자로 사이트에 로그인하여 쿼리를 재실행했는데 카운트는 여전히 0이었지만, 이번에는 디스코urs가(정확하게) 검토 대기 중인 사용자가 1명 있다고 보고했습니다.

보통 검토 대기 사용자는 관리자 주소로 즉시 알림 이메일이 도착하는데, 이번에는 절대 전송되지 않은 것으로 확신합니다. 이제 거의 반대되는 문제가 발생했네요!

*수정 - 방금 검토 대기 중인 사용자가 2명이라는 알림을 받았습니다(비정상적인 지연 후). 여전히 햄버거 메뉴 옆의 작은 빨간 아이콘에는 숫자 '1’이 표시되어 있었고, 클릭하여 대기열을 검토해 보니 위에서 생성한 제 가짜 사용자 1명만 표시되었습니다. 이를 승인했고, 디스코urs는 더 이상 검토할 사용자가 없다고 표시했습니다.

이후 쿼리를 다시 실행했는데 카운트는 0이었습니다.

죄송합니다. WHERE 절이 잘못되었음을 확인했습니다. User 대신 r.type = 'ReviewableUser'여야 합니다.

대신 이 쿼리를 실행해 주시겠어요?

SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'ReviewableUser' AND r.status = 1 AND users.approved = FALSE

로만님,
방금 또 유령 메시지를 받았습니다. 그리고 최신 메시지를 읽은 후 새 쿼리를 실행해 봤는데, 결과는 동일했습니다. count=0

그렇다면 다른 문제가 있는 거겠지. 조사해 볼게.

Paul_King님,

사이트에 승인되지 않은 사용자 중 검토 대상 객체가 연결되어 있지 않은 사용자가 있는지 확인해 주시겠어요? 아직까지 이 버그를 재현하지 못했어요.

다음은 이를 확인하기 위한 쿼리입니다:

SELECT COUNT(*) 
FROM users u
LEFT JOIN reviewables r ON r.target_id = u.id AND r.type = 'ReviewableUser'
WHERE approved = false AND r.id IS NULL

또한, 다음도 시도해 보세요:

SELECT COUNT(*) FROM users WHERE approved = false AND active = true

안녕하세요, Roman님 감사합니다.

첫 번째 쿼리의 결과는 다음과 같습니다:

관련이 있을지는 모르겠지만, 현재 포럼의 전신인 폐쇄된 Yahoo 그룹에서 가져온 게시글이 많습니다. 연속성과 검색 가능성을 위해 통합되었습니다. 해당 오래된 게시글(2000년대 초로 거슬러 올라감)의 작성자들은 현재 포럼에 계정이 없을 가능성이 높습니다.

두 번째 쿼리의 결과는 아래에 있습니다:

이것은 매우 흥미로웠습니다 - 승인되지 않은 계정으로 활동할 수 있는 방법은 무엇인가요? 관리자인 제 자신을 제외하고는요. 해당 사용자를 식별하도록 쿼리를 어떻게 수정해야 하나요?

그것은 승인을 기다리고 있다는 뜻입니다.

SELECT * FROM users WHERE approved = false AND active = true

사용자 이름은 사용자 프로필로 연결됩니다. 식별한 후 created_at 날짜를 공유해 주시겠어요? 그 날짜 주변에서 무언가를 변경했는지 알고 싶습니다.