네, 사용자가 삭제되면 해당 사용자가 RSVP한 이벤트에서 그 사용자를 제거합니다. 아마 그 코드가 이 문제를 일으키는 것 같습니다.
3개의 좋아요
에러에 포함된 모든 토픽 ID가 Events를 사용하는 토픽들이기 때문입니다.
음, 제가 삭제하려는 이 특정 사용자들은 RSVP를 하지 않았다고 확신하지만, RSVP가 활성화된 토픽이 이 토픽들뿐인 것일 수도 있겠네요.
3개의 좋아요
아, 알겠습니다.
@fzngagan 여기서는 안전하지 않은 .find(를 사용하고 있나요?
topics = Topic.find(topic_ids) if topic_ids
위에서 제가 방금 Follow에 push한 수정을 참고해 주세요(여기서는 여러 id를 다루므로 해결 방식이 달라질 수 있으니 where을 사용해야 할까요?)
3개의 좋아요
방금 업데이트했는데도 여전히 404가 나요.
1개의 좋아요
Bart, @fzngagan이 수정을 적용하고 확인하는 동안 잠시 기다려 주세요.
5개의 좋아요
수정 사항을 커밋했습니다. 문제가 해결되었기를 바랍니다. 확인 후 알려주세요.
5개의 좋아요
그렇게 하니 해결됐어요. 감사합니다!!
6개의 좋아요
최근 검토 대기열에서 "신규 사용자가 첫 게시물을 의심할 정도로 빠르게 입력했습니다"라는 이유로 표시된 게시물을 여러 번 확인했습니다.
더 자세히 살펴보니 해당 게시물들에 감시 대상 단어가 포함되어 있었지만, 검토 대기열에는 이 내용이 언급되어 있지 않았습니다.
"신규 사용자가 첫 게시물을 의심할 정도로 빠르게 입력했습니다"라는 플래그는 96%의 확률로 오작동하는 반면, “감시 대상 단어” 플래그는 100%의 확률로 정확합니다. 즉, 게시물이 감시 대상 단어로 인해 검토 대기열에 들어온 경우, 실제로는 주의가 필요한 게시물임이 100% 확실합니다. 따라서 "감시 대상 단어"가 "신규 사용자가 너무 빠르게 입력함"보다 우선순위를 가져야 한다고 생각합니다.
다음과 같은 상황을 상상해 보세요.
- 게시물이 "신규 사용자가 첫 게시물을 의심할 정도로 빠르게 입력했습니다"라는 이유로 검토 대기열에 들어옵니다. 이 게시물에는 “감시 대상 단어” 목록에 있는 보이지 않는 스팸 링크가 포함되어 있습니다. → 게시물이 승인됩니다. 아무도 보이지 않는 링크(예: 마침표 뒤에 숨겨진 링크)를 발견하지 못하기 때문입니다. → 실패!
- 게시물이 감시 대상 단어로 인해 검토 대기열에 들어옵니다("감시 대상 단어"가 "너무 빠르게 입력함"보다 우선). 이 게시물에는 “감시 대상 단어” 목록에 있는 보이지 않는 스팸 링크가 포함되어 있습니다. → 게시물이 거부되고 스팸 작성자가 "감시 대상 단어"로 인해 계정 삭제됨 → 성공!
5개의 좋아요
전적으로 동의합니다. 이는 경계선에 있는 버그입니다. @eviltrout 님, 누군가의 목록에 이 문제를 추가할 수 있을까요? @Roman 님이 여전히 담당하고 있는 것으로 보이는데, 어쩌면 그분에게 할당할 수도 있겠네요?
4개의 좋아요
8개의 좋아요
2.6.0.beta2 버전입니다. 참고로, 삭제된 것으로 보이는 대기열(topics) 항목들이 있습니다. 제가 추측하기로는 다음과 같은 방식으로 발생하는 것 같습니다:
- 사용자가 빠르게 타이핑하다가 게시물이 검토 대기열로 들어갑니다.
- 사용자가 자신의 주제를 삭제합니다(가능하다면), 아마도 다시 제출하기 위해서일 것입니다.
이것이 의도된 동작인지 확실하지 않습니다. 검토 대기열에서 제목은 비어 있지만, 게시물 본문은 남아 있고 사용자는 무음 처리(silenced)되어 있습니다. 사용자의 공개 프로필에서는 주제/게시물을 찾을 수 없습니다.
위 내용과 무관하게. 필터링 옵션에 대한 제안을 하나 드리겠습니다. 제 생각에 꽤 유용할 기능은 게시물/주제 유형에 대한 더 세밀한 필터입니다. 현재 유형(Types)에는 다음과 같은 항목이 있습니다:
'Flagged Post’와 'Queued Post’에는 주제(Topics)와 게시물(Posts)이 모두 포함되어 있습니다. 이 부분을 단순히 다음과 같이 변경하는 것이 꽤 유용할 것 같습니다:
검토 유형(Review Type):
- Flagged
- Queued
Flagged를 'User Flagged’와 'System Flagged’로 나누는 것도 고려해 볼 수 있습니다.
그리고 콘텐츠 유형에 대한 별도의 필터도 추가하면 좋겠습니다.
콘텐츠 유형(Content Type):
- Topic
- Post
- User
이것은 꽤 유용할 것이라고 생각합니다. 예를 들어, 게시물/답변 승인보다 주제 승인을 우선 처리하는 것이 훨씬 빠를 수 있습니다. 현재 필터에서는 'Grouped by Topic’를 제외하고 주제와 게시물을 구별하는 방법이 사실상 없습니다.
또 다른 제안은 검토 대기열 UI를 조정하여 주제와 게시물을 더 쉽게 구별할 수 있도록 하는 것입니다. 현재 이 정보는 작은 회색 텍스트로 표시됩니다(예: Queued Post, Queued Topic, Flagged Post, Flagged Topic). 텍스트 크기는 게시물/주제의 카테고리 및 태그와 같은 크기입니다.
제 경우, 해당 항목이 주제인지 게시물/답변인지 바로 명확하지 않으며, 두 가지를 자주 혼동합니다.
몇 가지 아이디어:
- 게시물 항목의 ‘Topic Title’ 섹션을 조정하여 답글 아이콘을 추가하고, 주제 항목보다 작게 만들며, 'RE:'라는 텍스트를 포함하도록 합니다.
- 항목 유형(Topic/Post)의 텍스트 크기/강조를 높입니다.
2개의 좋아요
토픽과 게시물을 승인하려고 하면 500 에러가 발생합니다. 현재 2.6.0.beta3 버전을 사용 중입니다. 로그는 다음과 같습니다:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
잠재적으로 관련이 있을 수 있는 정보로, 과거에 Akismet을 설치했다가 제거한 적이 있습니다 (rake 태스크도 실행함). 자세한 내용은 여기에서 확인하세요: Feedback on the new Review Queue (2019) - #210 by markersocial
해당 항목들은 지난 60일 이내에 생성된 것입니다 (auto_handle_queued_age: 60). 오래된 게시물(약 2개월 전)과 최근 게시물(지난 3시간 이내) 모두 시도해 보았습니다.
사용자 승인(Type: User)은 정상적으로 작동하며, 대기 중인 토픽/게시물의 ‘사용자 삭제’ 옵션도 정상적으로 작동합니다.
2개의 좋아요
@Roman 이거 진짜 이상하네요 - 여기서这么大的 정수는 어떻게 나오는 건가요?
6개의 좋아요
알림을 생성하려고 할 때 오류가 발생합니다:
아마도 우리는
일부 ID를 int 타입으로 저장하고 있는 것은 아닌지 의심됩니다. Rails 5.1부터 기본 키에 BIGINT(8)를 사용하기 시작했습니다.
@markersorcial 다음 쿼리의 결과를 공유해 주시겠어요?
Notification.count
User.count
Topic.count
4개의 좋아요
확인해 주셔서 감사합니다 
네, 쿼리 결과는 다음과 같습니다:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
3개의 좋아요
업데이트: Sidekiq를 확인해 보니, 다음과 유사한 오류로 실패한 작업이 많이 보입니다:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
아직까지 확인한 작업 유형은 다음과 같습니다:
Jobs::PostAlert (가장 흔함)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
1개의 좋아요
그 숫자들 중 어느 것도 최대 크기를 초과하지 않아야 합니다. @Roman, 다른什么地方이 정수 값을 덮어쓰고 있는 건 아닌지 궁금하네요.
3개의 좋아요
그러면 다른 원인이 있겠네요. 분명히 뭔가 문제가 있는 것 같고, 리뷰 대기열에 국한된 문제는 아닙니다.
이 작업들은 알림을 생성하는데, 이것들도 실패하고 있습니다:
또한, 이런 식으로 시도해 보면:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
다른 에러가 발생합니다:
ActiveModel::RangeError: 1311344111111 is out of range for ActiveModel::Type::Integer with limit 4 bytes
이렇게 해도 같은 에러가 나요:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERROR: integer out of range
6개의 좋아요
@markersocial PostgreSQL 로그가 오류에 대한 더 많은 정보를 제공해 줄 수 있을 것 같아. 확인해 줄 수 있어?
로그 위치를 모르겠다면 아래를 참고해:
5개의 좋아요
당신들의 모더레이터는 플래그된 게시물을 서로 쉽게 논의할 수 있고, 그 기록이 검토 대기열(Review Queue)에 유지되는 기능을 높이 평가합니다. 같은 기능을 대기열(Queued) 게시물에도 추가할 수 있을까요? 우리는 approve_post_count 설정을 사용하여 신규 사용자의 첫 5개 게시물에 대한 승인을 요구합니다. 이 첫 5개 게시물이 대기열(Queued) 게시물이 되는데, 모더레이터 간의 논의가 필요할 경우 검토 대기열과 분리된 개인 메시지(PM)를 시작해야 하고, 이로 인해 논의 기록이 사라집니다.
3개의 좋아요