네, 그게 문제인 것 같아요. LLM이 코드가 항목 목록을 잘 처리하지 못한다고 판단해서 500 에러가 발생한다고 하네요.
그러면 이건 Contribute > Bug 채널의 영역에 해당하나요?
버그인 것 같고, 간단한 수정으로 해결될 것 같지만, 새로운 카테고리 구조를 정확히 이해하지 못하겠습니다. (본인이라면 완전히 이해하지 못한 코드는 제출하지 않을 것입니다.)
또한 데이터베이스의 상태가 수정이 필요한 다른 버그에서 비롯된 것인지에 대한 문제도 있습니다.
이 주제에는 참여자가 단 세 명뿐이므로, 새로운 버그 리포트 주제를 개설하는 것이 도움이 될 수 있습니다. 관리자가 원한다면 언제든 병합하거나 카테고리를 변경할 수 있습니다.
음, 사실 Contribute > Bug 토픽을 본 적이 없었고, 기억을 더듬어봐도 거기서 글을 쓴 적이 없는 것 같습니다. 또한 버그인지 아닌지를 정확히 판별할 수 있는 수준의 기술력도 되지 않을 것 같고요.
게다가 네가 말한 대로 맞을 수도 있겠네요. 과거의 DB 문제 때문에 이 취약한 지점이 발동된 것일 수 있으니까요.
관리자 계정에 다시 접근할 수 있게 해야 한다는 요구사항은 시급하지만, 그 부분은 결국 하늘에 맡길 수밖에 없는 것 같습니다. 그래도 적어도 문제의 원인을 찾은 것 같으니, 이제 잘 될 거라고 기대해 봅니다!
도와줘서 고마워요. ![]()
그리고 이것이 관리자 권한을 사용자 계정으로 취소하고, 아마도 модератор 계급으로 변경하면 로그인 시 이 문제를 우회할 수 있을지 궁금합니다.
백업을 마친 후에 직접 테스트해 볼 수도 있겠네요.
걱정되는 점은 데이터 손실이나, 오류가 발생하지 않는 것 같아 정상적으로 보이지만 실제로는 어떤 부분이 깨졌는지 확인할 수조차 없는 상황을 맞이할 수 있다는 것입니다. ![]()
별말씀을요. 재밌었습니다.
아마 SQL로 그 중복 항목을 제거할 수 있는 작은 방법이 있을 수도 있지만, 개인적으로는 가볍게 그렇게 하지는 않을 것 같습니다.
또한 LLM에 따르면, rails 콘솔을 사용해 10줄짜리 ruby 함수를 업데이트하고 강화하는 것도 가능하다고 합니다. 적어도 그것은 안전해야 할 것인데, 재시작 시 디스크에서 실제 ruby 코드가 다시 로드되니까요.
이 코드를 붙여넣어 두려고 합니다. LLM이 생성한 테스트되지 않은 코드로, 실행 중인 시스템에 rails 콘솔에서 적용할 monkey patch 형태로 제시되어 있습니다. 또한 이 취약성으로 인해 발생하는 오류에 대한 LLM이 제안한 수정 사항도 포함되어 있습니다:
# CurrentUserSerializer를 다시 열어 손상된 메서드를 오버라이드합니다
class CurrentUserSerializer < ApplicationSerializer
def has_new_upcoming_changes
last_visited = object.custom_fields["last_visited_upcoming_changes_at"]
# 프리로더에 의해 배열로 캐시된 경우 문자열을 추출합니다
last_visited = last_visited.first if last_visited.is_a?(Array)
return false if last_visited.blank? && object.created_at < Discourse.site_creation_date + 1.hour
cutoff = last_visited.present? ? Time.zone.parse(last_visited.to_s) : object.created_at
UpcomingChangeEvent.added.not_backfilled.where("created_at > ?", cutoff).exists?
end
end
관리자 권한 취소
다음 작업은 원래 잠겨진 관리자 사용자 계정에 적용됩니다:
-
관리자 권한 + Moderator(모더레이터) 권한 부여 = 로그인 실패/동일한 오류 발생.
-
Moderator(모더레이터) 권한 취소
- 첫 번째 로그인 시 오류는 없으나, 2단계 인증/로그인 중 로딩 스피너가 멈춤
- 약 10분 정도 대기함 (서버가 로그인 시 부하 증가를 표시함), 여전히 반응 없음
- 하지만 “활성” 사용자 탭에는 해당 사용자가 Xm 전에 로그인한 것으로 표시됨. hmm

- 다른(개인) 창에서 두 번째 로그인을 시도하니 성공!
즉, 이는 메시지/채팅 등을 읽어야 할 수 있는 관리자 사용자를 위한 임시 해결책이 되지만, 근본적인 문제를 해결하지는 못합니다.
다음으로, 다른 관리자 계정으로 로그인된 전 관리자 사용자 계정에 Grant Admin(관리자 권한 부여)을 실행
- 로그인된 상태에서 관리자 권한 업데이트 메시지가 성공을 나타내며 도착함.
- 페이지를 새로고침하니 다시 오류가 발생함
9월 28일부로 “Git hang” 토론이 닫혀서 글을 올릴 수는 없지만, 몇 분 전 느린 동작을 발견했을 때 아, 또 git이 사라져서 문제가 생기는 건가? 하고 생각했는데, 정말로 그 시점에 downdetector.com에서 GitHub의 대규모 장애가 발생하고 있는 모습을 확인할 수 있었습니다. ![]()