수정된 게시글이 성공적으로 저장되었음에도, iOS의 DiscourseHub에서 이미 렌더링된 게시글이 토픽을 새로고침할 때까지 가끔 구식 상태로 남아있는 간헐적 문제를 겪고 있습니다.
환경
프로덕션 사이트는 제가 개인적으로 학습 아카이브로 사용하는 자체 호스팅 Discourse 설치 환경입니다.
오늘 이 문제를 재현했을 당시의 환경은 다음과 같습니다:
- 클라이언트: iPhone용 DiscourseHub
- iOS: 27.0.1
- 프로덕션 Discourse:
v2026.10.0-latest +112 - 사이트: 자체 호스팅, 개인 학습 아카이브
- 기본 iOS 브라우저: iCab Mobile
무관한 로컬 다운로드 문제로 인해 기본 브라우저를 iCab Mobile로 변경했습니다. 그러나 이 재현은 외부 브라우저를 여는 것이 아니라 DiscourseHub 내부에서 Discourse 사이트를 사용하던 중 발생했으므로, 현재로서는 기본 브라우저 선택이 관련이 있다고 생각하지 않습니다.
실제 워크플로우
이 문제를 발견한 토픽에는 강의 슬라이드를 나타내는 약 50개의 게시글이 포함되어 있었습니다.
제 일반적인 워크플로우는 다음과 같습니다:
- 강의 슬라이드 이미지를 포함한 게시글을 생성합니다;
- 나중에 토픽을 순차적으로 진행합니다;
- 각 기존 게시글을 수정합니다;
- 이미 게시된 슬라이드 이미지 아래에 OCR 텍스트/메모를 추가합니다;
- **수정 저장(Save Edit)**을 누르고 다음 슬라이드로 이동합니다.
따라서 이는 인위적인 빠른 수정이 아닙니다. 강의 슬라이드 이미지 게시글에 OCR 텍스트를 점진적으로 추가하는 정상적인 학습 워크플로우입니다.
토픽의 앞부분 게시글의 경우, 수정 저장을 누르면 예상대로 표시된 게시글이 즉시 수정된 새 내용으로 대체되었습니다.
같은 토픽의 후반부에서는 다음과 같은 사례를 겪었습니다:
- 게시글을 수정하고 OCR 텍스트를 추가했습니다.
- 수정 저장을 눌렀습니다.
- 수정이 성공적으로 저장되었습니다.
- DiscourseHub에 표시된 게시글은 이전 내용 그대로 남아있었습니다.
- 페이지를 새로고침하면 이미 저장된 수정 내용이 즉시 표시되었습니다.
즉, 수정 자체는 성공적으로 이루어진 것으로 보입니다. 구식 상태인 부분은 게시글의 이미 로드된 클라이언트 표현인 것 같습니다.
개발 테스트
그 후 현재 업스트림 main 브랜치에서 완전히 깨끗한 개발 인스턴스를 생성했습니다:
833e1576d47 DEV: Update README.md note on self-hosting (#44320)
프로덕션 토픽의 구조를 모방하기 위해 모든 게시글에 이미지를 포함하여 60개의 게시글이 있는 토픽을 생성했습니다.
그 후 Linux의 Firefox에서 워크플로우를 반복하여 기존 이미지 게시글에 텍스트를 수정했습니다.
첫 번째 테스트에서 게시글 19번 근처에서 가능한 구식 업데이트를 한 번 목격했습니다.
그러나 실험을 더 신중하게 반복한 결과(새로운 60개 게시글 토픽을 생성하고 게시글을 순차적으로 수정하는 것 포함), 현재 main 브랜치에서 Firefox/Linux 환경에서 프로덕션 동작을 재현하지 못했습니다.
그곳에서는 수정 후 수정 저장을 누르면 게시글이 즉시 다시 페인팅되었습니다. 이는 토픽의 첫 번째 게시글 그룹을 훨씬 넘어선 경우에도 마찬가지였습니다.
이로 인해 토픽 페이지네이션이나 일반적인 20개 게시글 스트림 청크 자체가 원인이라는 확신이 줄어들었습니다.
다음 테스트
프로덕션 재현은 홈스크린 PWA가 아니라 iOS용 DiscourseHub에서 이루어졌습니다.
따라서 다음으로 계획한 비교는 다음과 같습니다:
- 현재 업스트림 Discourse 개발 인스턴스;
- 동일한 60개 이미지 게시글 토픽;
- 동일한 iOS 27.0.1을 실행 중인 iPhone;
- 먼저 DiscourseHub 사용;
- 동일한 iPhone에서 대조군으로 Safari 사용;
- 선택적으로 홈스크린 웹 앱을 또 다른 비교 대상으로 사용;
- 동일한 OCR 스타일 워크플로우를 사용하여 게시글을 순차적으로 수정.
현재 제 개발 노트북은 eduroam 네트워크에 연결되어 있어, 로컬 개발 서버를 iPhone에 직접 노출하는 것이 쉽지 않습니다.
이 문제를 좁혀가는 데 다음 단계로, DiscourseHub에서 동일한 iPhone으로 현재 main 개발 인스턴스를 실행하는 것이 올바른 방법일까요?
그렇다면, Discourse 팀이 테스트를 위해 로컬 개발 인스턴스를 iPhone / DiscourseHub에 노출하는 데 선호하는 방식이 있을까요? 가능하면 HTTPS를 통해?
다음 발생 시 구식 게시글을 새로고침하지 않은 상태로 두고 화면 녹화를 캡처할 수도 있습니다. 그러면 성공적인 저장/서버 상태를 이미 열려 있는 DiscourseHub 클라이언트가 표시하는 내용과 직접 비교할 수 있을 것입니다.
관련이 있을 수 있는 관찰 사항
이 동작은高层次에서 PR #43285, “토픽 목록에서 이벤트 날짜 새로고침” 작업 중 겪었던 구식 클라이언트 상태 문제와 유사하게 느껴집니다.
그것은 다른 코드 경로였고, 제가 동일한 버그라고 제안하는 것은 아닙니다.
그러나 관찰된 실패는 유사했습니다: 서버 측 상태가 정확할 수 있음에도, 관련 새로고침/재수화가 일어나기까지 이미 로드된 클라이언트가 구식 상태를 계속 표시했습니다.
이벤트 날짜 문제에서는 타이밍에 따라 이미 열려 있는 다른 클라이언트에서 A/B 상황을 관찰할 수 있었습니다.
이로 인해 이 수정 문제도 수정 자체의 실패가 아니라 알림/모델 업데이트/렌더링 체인의 어딘가에 있을 수 있다는 생각이 듭니다.