# iOS PWA: «Сохранить» застревает, редактор недоступен, продиктованный текст теряется **URL:** \ **Category:** Bug\ **Tags:** composer, pwa, ios\ **Created:** [21.Октябрь.2026 19:52:55 UTC](https://meta.discourse.org/t/ios-pwa-save-edit-stuck-in-saving-composer-inaccessible-and-dictated-text-lost/415354 "2026-10-21T19:52:55Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\ **Post date:** [21.Октябрь.2026 19:52:55 UTC](https://meta.discourse.org/t/ios-pwa-save-edit-stuck-in-saving-composer-inaccessible-and-dictated-text-lost/415354/1 "2026-10-21T19:52:55Z")
21 октября 2026 года при редактировании существующего поста в моем self-hosted инстансе Discourse возникла периодическая проблема. Композер застрял в состоянии **Сохранение** (Saving), и я не смог вернуться к редактору, чтобы восстановить продиктованный текст. После этого я изучил логи доступа Caddy и nginx, а также историю ревизий постов в Discourse. ## Окружение - **Клиент:** iPhone 16 Pro, PWA Safari на домашнем экране - **iOS:** 27.0.1 - **Discourse:** `2026.10.0-latest +406 commits`, как показано в админ-панели позже в тот же день (доступно 162 новых изменения) - **Хостинг:** self-hosted, частный учебный архив - **Обратный прокси:** Caddy v2.11.4, предоставляющий HTTP/3 поверх QUIC - **Бэкенд:** Discourse nginx за Caddy с использованием Unix сокета - **Сеть:** сначала университетский Wi-Fi, затем мобильная сеть EE ## Что произошло Я редактировал пост, содержащий изображение слайда физики. Под изображением я продиктовал дополнительные математические заметки, включая дроби, и затем быстро нажал **Сохранить правку** (Save Edit). Голубая горизонтальная полоса **Сохранение** оставалась видимой внизу экрана и не завершалась. Я попытался коснуться полосы Сохранения, но это не открыло композер заново. В результате я не мог выделить или скопировать несохраненный текст в другое место. Я ждал дольше, чем обычно. **Только после того, как операция сохранения уже зависла, я вручную отключил Wi-Fi** , надеясь, что переключение на мобильную связь позволит запросу завершиться. Интерфейс не восстановился сразу. Я также столкнулся с буферизацией при попытке навигации с помощью логотипа сайта. Когда я снова смог редактировать пост, продиктованные дроби отсутствовали. ## Серверное расследование Соответствующее время составляло приблизительно **12:20 BST 21 октября 2026 года**. Мои логи 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 зафиксировал длительность приблизительно **110 мс** , тогда как nginx записал ответ HTTP **400** без выполнения контроллера обновления поста в Discourse. Множество других запросов, исходящих из мобильного соединения, также получили статус Caddy `0` примерно в то же время. Сам Caddy не перезапускался. Docker сообщает о нулевом количестве перезапусков с 15 октября, а в операционных логах нет соответствующих событий перезагрузки или завершения работы. ### Восстановление черновика Незадолго до инцидента были успешные запросы на сохранение черновика. Однако я помню предыдущее содержимое как слайд с изображением без дополнительных продиктованных текстов. Я ввел дроби позже и вскоре после этого нажал «Сохранить правку». Поэтому я **не могу установить, что отсутствующая диктовка была включена в один из успешных автосохранений**. Когда я впоследствии проверил ревизии поста, успешная ревизия в 12:20:55 содержала изображение, но не продиктованные дроби. Я также проверил текущие записи черновиков, но ни старый, ни новый ключ черновика темы не имели остаточного черновика на момент проверки. ## Ожидаемое поведение Если запрос на редактирование зависает или прерывается, я ожидаю, что композер сохранит свое несохраненное содержимое и предоставит возможность повторить попытку, отменить или вернуться к редактированию. В частности, интерфейс в идеале не должен делать несохраненный текст недоступным неопределенно долго, показывая состояние «Сохранение». ## Фактическое поведение Композер оставался недоступным, касание полосы «Сохранение» не открывало его заново, и продиктованный текст больше не был доступен при возобновлении редактирования. ## Вопросы 1. Ожидается ли, что композер останется недоступным неопределенно долго, пока запрос на редактирование находится в ожидании? 2. Существует ли механизм тайм-аута или восстановления, предназначенный для возобновления редактирования, когда сетевой запрос прерван? 3. Должна ли прерванная операция «Сохранить правку» сохранять текст в памяти или содержимое черновика, даже если запрос никогда не достигает контроллера обновления поста Rails? 4. Будет ли какая-либо клиентская журналирование или инструментация полезной, если это произойдет снова на iOS? Я понимаю, что изменение сети может объяснить окончательные отмены запросов. Однако интерфейс «Сохранение» уже завис **до того, как я вручную сменил сети**. Я не установил, исходила ли первоначальная задержка из JavaScript Discourse, сетевых компонентов iOS/WebKit или университетского соединения. ## Связанные обсуждения У меня есть существующее [обсуждение MPTCP / непрерывности соединения iOS](https://meta.discourse.org/t/multipath-tcp-mptcp-for-discoursehub-and-ios-safari-pwa-behind-caddy/414499/2), где я описал этот же инцидент с точки зрения транспорта. Я также ранее сообщал о том, что [отредактированные посты иногда остаются устаревшими в DiscourseHub на iOS](https://meta.discourse.org/t/edited-post-occasionally-remains-stale-until-refresh-in-discoursehub-on-ios/414121). В этой отдельной проблеме правки **успешно достигали сервера** , но уже отрендеренный пост не обновлялся до обновления страницы. Другой пользователь также сообщил об этом поведении. Я не знаю, разделяют ли эти две проблемы общую причину. Текущий инцидент отличается тем, что первоначальный запрос на редактирование поста не был успешно обработан. Я также нашел два более ранних сообщения о композере, застрявшем в режиме «Сохранение»: - [После редактирования полоса «Сохранение» застревает](https://meta.discourse.org/t/after-editing-saving-bar-is-stuck/259347) (2023) - [Композер застревает в состоянии «Сохранение», когда тема требует модерации](https://meta.discourse.org/t/composer-stuck-in-saving-state-when-topic-requires-moderation/392960) (2026) В обоих случаях были идентифицированы разные причины, и я не предполагаю, что они объясняют этот инцидент. Я прикрепил ZIP-архив [discourse\_ios\_save\_evidence\_2026-10-21\_domain\_redacted.zip](https://meta.discourse.org/uploads/short-url/heL5d3Q9DfAfnurGBdTgO8ovA9B.zip) (6,3 КБ), содержащий выбранные, отредактированные диагностические выгрузки Caddy/nginx, информацию о ревизиях и хронологию, описанную выше. Я буду признателен за любые советы относительно того, как композер должен восстанавливаться из зависшего запроса, особенно когда несохраненные изменения нельзя скопировать до прерывания сети.