2026년 10월 21일에 셀프 호스팅된 Discourse 인스턴스에서 기존 게시물을 편집하던 중 간헐적인 문제가 발생했습니다. 컴포저(Composer)가 저장 중(Saving) 상태로 고정되어 편집기로 돌아가서 독음으로 입력한 텍스트를 복구할 수 없었습니다.
이후 Caddy 및 nginx 액세스 로그와 Discourse 게시물 수정 이력을 조사했습니다.
환경
-
클라이언트: iPhone 16 Pro, Safari 홈 화면 PWA
-
iOS: 27.0.1
-
Discourse: 해당 날 이후 관리자 대시보드에 표시된
2026.10.0-latest +406 commits(새로운 변경 사항 162개 사용 가능) -
호스팅: 셀프 호스팅, 개인 연구 아카이브
-
리버스 프록시: QUIC 기반 HTTP/3을 제공하는 Caddy v2.11.4
-
백엔드: Caddy 뒤의 Unix 소켓을 사용하는 Discourse nginx
-
네트워크: 초기에는 대학 Wi-Fi, 이후 EE 셀룰러 네트워크로 전환
발생한 상황
물리학 강의 슬라이드 이미지가 포함된 게시물을 편집하고 있었습니다.
이미지 아래에 분수 기호를 포함한 추가 수학 노트를 독음으로 입력한 후, 빠르게 편집 저장(Save Edit) 버튼을 눌렀습니다.
화면 하단의 파란색 수평 저장 중(Saving) 바가 계속 표시되었고 완료되지 않았습니다.
저장 중 바를 터치해 보았지만 컴포저가 다시 열리지 않았습니다. 이로 인해 저장되지 않은 텍스트를 다른 곳에 선택하거나 복사할 수 없었습니다.
보통보다 더 오래 기다렸습니다.
저장 작업이 이미 멈춘 후에야 Wi-Fi를 수동으로 비활성화하여 셀룰러로 전환하면 요청이 완료되기를 희망했습니다.
인터페이스는 즉시 복구되지 않았습니다. 사이트 로고를 사용하여 탐색하려 할 때에도 버퍼링 현상이 발생했습니다.
다시 게시물을 편집할 수 있을 때, 독음으로 입력한 분수 기호들이 사라져 있었습니다.
서버 측 조사
관련 시간은 대략 2026년 10월 21일 BST 오후 12:20경입니다.
Caddy 로그는 다음과 같습니다:
| 시간 (BST) | 요청 | 결과 |
|---|---|---|
| 12:19:39 | POST /drafts.json |
200 |
| 12:19:40 | POST /uploads.json |
200 |
| 12:19:44 | POST /drafts.json |
200 |
| 12:20:08 | PUT /posts/70695 |
Caddy 상태 0 |
| 12:20:55 | PUT /posts/70695 |
200 |
실패한 PUT 요청은 HTTP/3을 사용했습니다. Caddy는 약 110ms의 지속 시간을 기록했고, nginx는 Discourse 게시물 업데이트 컨트롤러 실행 없이 HTTP 400 응답을 기록했습니다.
셀룰러 연결에서 시작된 수많은 다른 요청들도 대략 같은 시간에 Caddy 상태 0을 받았습니다.
Caddy 자체는 재시작되지 않았습니다. Docker 보고에 따르면 10월 15일 이후 재시작 횟수는 0회이며, 운영 로그에는 이에 해당하는 재로드 또는 종료 이벤트가 없습니다.
초안 복구
사건 직전에 성공적인 초안 저장 요청들이 있었습니다.
그러나 저는 이전 내용을 추가 독음 텍스트 없이 슬라이드 이미지만 있는 것으로 기억합니다. 분수 기호들을 나중에 입력하고 곧바로 편집 저장을 눌렀기 때문입니다.
따라서 누락된 독음 내용이 두 번의 성공적인 자동 저장 중 어느 하나에 포함되었는지 확인할 수 없습니다.
이후 게시물 수정 이력을 검사했을 때, 12:20:55에 성공한 수정 버전에는 이미지는 있었지만 독음으로 입력한 분수 기호들은 없었습니다.
현재 초안 기록도 확인했지만, 검사 시점에 구버전 maupun 신버전 토픽 초단 키 모두 남은 초단이 없었습니다.
기대 동작
편집 요청이 멈추거나 중단되는 경우, 컴포저가 저장되지 않은 내용을 보존하고 재시도, 취소 또는 편집 복귀 방법을 제공하기를 기대합니다.
특히, '저장 중’을 표시하면서 저장되지 않은 텍스트를 무기한 접근 불가능하게 만드는 것은 피해야 합니다.
실제 동작
컴포저는 접근 불가능한 상태를 유지했으며, 저장 중 바를 터치해도 다시 열리지 않았고, 편집이 재개되었을 때 독음 텍스트는 더 이상 사용할 수 없었습니다.
질문
-
편집 요청이 처리 중인 동안 컴포저가 무기한 접근 불가능한 상태로 남아있는 것이 예상된 동작인가요?
-
네트워크 요청이 중단될 때 편집을 복구하도록 설계된 타임아웃이나 복구 메커니즘이 있나요?
-
요청이 Rails 게시물 업데이트 컨트롤러에 도달하지 않더라도, 중단된 편집 저장 작업은 메모리에 있는 텍스트나 초단 내용을 보존해야 하나요?
-
iOS에서 이것이 다시 발생할 경우 유용할 특정 클라이언트 측 로깅 또는 계측(instrumentation)이 있나요?
네트워크 변경이 최종적인 요청 취소의 원인을 설명할 수 있다는 점은 인정합니다. 그러나 저장 인터페이스가 제가 수동으로 네트워크를 변경하기 전에 이미 멈춰 있었습니다.
초기 지연이 Discourse JavaScript, iOS/WebKit 네트워킹, 또는 대학 연결에서 비롯되었는지 여부는 아직 확인하지 못했습니다.
관련 토론
이전 MPTCP / iOS 연결 연속성 토론에서 동일한 사건을 전송(transport) 관점에서 설명한 적이 있습니다.
또한 이전에 iOS에서 DiscourseHub에서 편집된 게시물이 가끔씩 최신 상태가 아닌 문제를 보고한 적이 있습니다. 그 별개의 이슈에서는 편집이 서버에 성공적으로 도달했음에도 이미 렌더링된 게시물이 새로고침 전까지 업데이트되지 않았습니다. 다른 사용자도 동일한 동작을 인지했다고 보고했습니다.
두 문제가 동일한 원인인지 알지 못합니다. 현재 사건의 경우, 초기 게시물 편집 요청이 성공적으로 처리되지 않았기 때문에 다릅니다.
‘저장 중’ 상태로 고정된 컴포저를 언급한 이전 보고 두 건도 찾았습니다:
-
편집 후 “저장 중” 바가 고정됨 (2023)
두 건 모두 다른 원인이 식별되었으며, 이번 사건을 설명한다고 가정하지는 않습니다.
선택적, 마스킹된 Caddy/nginx 진단 추출물, 수정 정보 및 위에서 설명한 연대기가 포함된 ZIP 파일 discourse_ios_save_evidence_2026-10-21_domain_redacted.zip (6.3 KB)을 첨부했습니다.
특히 네트워크 중단 전에 저장되지 않은 변경 사항을 복사할 수 없는 상황에서, 컴포저가 정체된 요청에서 어떻게 복구하도록 의도되어 있는지 조언을 주시면 감사하겠습니다.