Moin
12월 28, 2025, 10:18오후
1
오늘 메타에서 502 오류가 발생했습니다. 팝업 창을 제외하고는 다른 이상한 동작은 발견하지 못했습니다. 원인이 무엇인지 정확히 알 수 없고, 일관되게 재현되지는 않지만 몇 번은 성공적으로 재현할 수 있었습니다.
제가 수행한 작업은 다음과 같습니다:
사이드바의 + 버튼을 사용하여 이전에 대화한 적이 있지만 현재 사이드바에 표시되지 않는 사람과의 DM 채팅을 열었습니다.
전체 화면 채팅 버튼을 사용했습니다.
브라우저 창 크기를 더 작게 변경했습니다.
다시 브라우저 창을 전체 화면으로 만들었습니다.
전체 화면 채팅에서 작은 채팅 창으로 다시 전환했습니다.
약 7초 후, 아래 이미지가 표시되었습니다.
브라우저 콘솔에는 다음과 같은 내용이 표시되었습니다:
제가 가진 정보는 이것뿐입니다. 누군가 저보다 더 많은 것을 파악해 주기를 바랍니다. 도움이 된다면, 이 오류를 재현하는 방법을 보여주는 동영상을 가지고 있습니다.
1개의 좋아요
Moin
12월 28, 2025, 10:30오후
2
이 단계 때문에 그런 것일까요? 해당 채팅 필터에서 누군가를 검색할 때 이런 일이 발생하는 것일까요?
1개의 좋아요
Moin
12월 28, 2025, 11:51오후
3
재현에 필요한 단계를 찾은 것 같습니다: 채팅 필터에 "L"을 입력하면 약 30초 후에 오류가 발생합니다.
2개의 좋아요
채팅 그룹 직렬화기에서 채팅이 활성화된 사용자의 수를 반환하는 데 사용되던 잘못된 쿼리가 있었습니다. 이 쿼리는 사용자의 계정에 대해 약 30초가 소요되었는데, 이는 저희 호스팅의 요청 타임아웃 시간입니다(이 때문에 “무작위로” 문제가 발생했던 것입니다).
main ← fix-chatables-timeout
merged 06:05PM - 29 Dec 25 UTC
When searching for `chatables`, groups matching the search term are serialized. … The serializer was computing `chat_enabled_user_count` by loading **ALL** users from each group into memory and iterating through them in Ruby:
```ruby
object.human_users.count { |user| user.user_option&.chat_enabled }
```
On large sites, groups like `trust_level_0` can have tens of thousands of users. This caused serialization to be extremely slow, potentially hitting request timeouts and resulting in 502 errors.
The fix uses a SQL COUNT query instead, which completes in milliseconds. The result is also memoized since `can_chat` calls `chat_enabled_user_count` internally.
Ref: https://meta.discourse.org/t/392286
3개의 좋아요
Moin
12월 30, 2025, 2:17오후
6
음, 병합된 것을 확인했습니다. 그러면 더 이상 오류가 발생하지 않는다는 뜻인가요?
Moin
12월 30, 2025, 2:25오후
8
네, 가끔은 그렇게 됩니다. 이상하긴 한데, 어떤 때는 몇 초면 사용자가 표시되기도 하고, 어떤 때는 실패하곤 합니다.
이런 일이 발생하면 네트워크 탭과 시간이 오래 걸리는 요청을 보여줄 수 있을까요?
Moin
12월 30, 2025, 3:00오후
10
하아. 마우스 두 번 클릭하면 된다는 듯이 묻는군.
한번 해볼게.
Moin
12월 30, 2025, 3:06오후
11
이것이 내가 말하는 몇 초가 걸리거나, 가끔은 실패한다는 의미입니다:
아, 결국 해결했어요
첫 번째 수정은 문제의 일부만 다뤘습니다
흥미롭게도 이 문제는 “일반” 사용자에게만 영향을 미쳤고 "관리자"에게는 영향을 주지 않아서, 제가 직접 재현하지 못했던 겁니다
그룹을 검색할 때 결과는 알파벳 순서로 반환됩니다. 관리자는 모든 그룹을 볼 수 있으므로 "L"에 대한 첫 10개 결과는 'a’로 시작하는 작은 그룹들(예: “ai-personas” 및 기타 비공개 그룹)이었어요. 일반 사용자는 가시성이 더 제한적이므로, 결과에는 대규모 신뢰 수준 그룹이 포함되었습니다
일반 사용자가 보는 것:
trust_level_0: 62,506명
trust_level_1: 34,494명
trust_level_2: 4,727명
trust_level_3: 39명
trust_level_4: 13명
기타 더 작은 그룹들
총: 약 102,000명의 사용자 로드
관리자가 보는 것:
a*****: 4명
a*****: 76명
a*****: 0명
a*****: 2명
ai-personas: 138명
등등
총: 약 240명의 사용자 로드
main ← fix-chatables-timeout-regular-users
merged 09:20PM - 30 Dec 25 UTC
The previous fix (a5199830d1) updated the serializer to use SQL COUNT instead of… loading all users in Ruby, but forgot to remove the `.includes(users: :user_option)` from the service. This meant we were still loading ALL users of every matching group... for nothing! 😅
This caused 502 timeouts for regular users but not admins 🤔
Why? When searching groups, results are returned alphabetically. Admins can see all groups, so their first 10 results for "L" were small groups starting with 'a'. Regular users have limited visibility, so their results included the massive trust_level groups:
- trust_level_0: 62,506 users
- trust_level_1: 34,494 users
- trust_level_2: 4,727 users
That's 100k+ users being loaded into memory for no reason! 💥
The fix removes the unnecessary `.includes()` and adds a spec to prevent regression, plus a comment explaining why we shouldn't eager load users here.
Ref - https://meta.discourse.org/t/392286
1개의 좋아요
데이터를 "익명화"하는 데 실패하고 예시를 만들어내는 나
1개의 좋아요
Moin
12월 30, 2025, 9:30오후
15
그룹의 정식 이름에 L이 포함되어 있어서, 그것이 이유인지 아니면 단순히 무작위로 든 예시인지 확신이 서지 않았습니다.
채팅 필터에서 그룹을 검색할 때 비효율적인 데이터베이스 쿼리가 추가로 실행되고 있었거든요. 검색어와 일치하는 그룹에 따라 쿼리 완료에 매우 오랜 시간이 걸릴 수 있었는데, 때로는 요청 타임아웃을 초과하기도 했어요.
이것이 느린 쿼리의 원인이었죠.
