Mobile: a channel-section edit that doesn't publish within 5s is silently dropped on the next provider rebuild
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 70/100
Hướng nghiên cứu
Đọc mobile/lib/features/channels/channel_sections/channel_sections_provider.dart và channel_sections_manager.dart, đặc biệt là ChannelSectionsNotifier.build(), dispose() và markDirty(). Theo dõi cách xử lý timer debounce đang chờ khi provider được dựng lại, sau đó chạy các bài kiểm thử channel-sections liên quan. Hoàn tất khi chỉnh sửa cục bộ đang chờ được công bố không bị loại bỏ khi dựng lại và có bài kiểm thử hồi quy bao quát hành vi này.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug
On mobile, editing a channel section (create/rename/delete/reorder/assign) schedules the relay publish on a 5-second debounce timer. If anything causes the channelSectionsProvider to rebuild before that timer fires — e.g. a relay reconnect while backgrounding/foregrounding the app — the pending publish is cancelled and discarded, not flushed. The edit stays in local storage on that device only; it never reaches the relay, so no other device (including the same mobile app after a fresh rebuild) ever sees it.
Steps to reproduce
- On mobile, open a channel and move it into a different section (or create/rename/delete a section).
- Within 5 seconds, background the app (or otherwise cause a relay reconnect — e.g. brief network drop) so the relay session status transitions and the provider rebuilds.
- Return to the app, or check the same section on desktop/another device.
- The edit is gone — it was never published, and it does not reappear.
Expected behavior
A local edit that hasn't published yet should survive a provider rebuild — either by flushing the pending publish before tearing down the old manager, or by re-arming the debounce on the new manager instance — so it is never silently dropped.
Version and platform
- Buzz version: 0.5.14
- OS: macOS 26.5.2 (Apple Silicon) — bug is in shared mobile client code, platform-independent
Logs / additional context
Root cause, confirmed against current source:
mobile/lib/features/channels/channel_sections/channel_sections_manager.dart:288—markDirty()only arms a 5-secondTimerbefore calling_publish(); nothing ties it to the manager's lifecycle beyond that timer.mobile/lib/features/channels/channel_sections/channel_sections_manager.dart:170—dispose({bool flushPending = true})will flush a pending publish ifflushPendingis true.mobile/lib/features/channels/channel_sections/channel_sections_provider.dart:29—ChannelSectionsNotifier.build()calls_manager?.dispose(flushPending: false)on every rebuild, explicitly discarding any pending publish instead of flushing it.build()watchesrelaySessionProvider(session connect status) andactiveCommunityProvider, both of which commonly change during normal mobile use — e.g.relay_session.dartpauses the session on app background and reconnects on resume (_paused,SessionStatus.reconnecting→connected), which re-triggersbuild().
So a mobile edit followed within 5 seconds by an app background/foreground cycle (a very ordinary user action) loses the publish permanently, with no error, no retry, and no UI signal — it looks identical to a successful but not-yet-synced edit.
This is separate from #5797 (mobile UI not repainting after a local mutation — that one self-corrects once anything triggers _onChanged()). This bug is about the relay publish itself being discarded, so there is nothing to self-correct: other devices never receive the change.
Reported from a self-hosted single-user deployment; reproduced by reading the source, not by capturing a live network trace of the drop in progress.
- Ngôn ngữ chính
- Rust
- Star
- 35.6k
- Fork
- 4.7k
- Merge trung bình
- 2 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 202
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của block/buzz
-
Desktop: avatars blink (blank → gray → photo) whenever a new message group rendersCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 80/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Mobile: opening an attachment names the file after the link text instead of the imeta filenameCó thể đã có người làm @wenhaoone đã nhận 6 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Desktop: private project home channels show no lock icon in the sidebarCó thể đã có người làm @Bartok9 đã nhận 7 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Desktop crashes on launch: undefined is not an object (evaluating 'e.participantPubkeys.map')Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
defect
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 2 ngày
-
enhancement user-priority/P3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày