Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Mobile: a channel-section edit that doesn't publish within 5s is silently dropped on the next provider rebuild

Đang mở Phù hợp với người mới
#8,140 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
mobile

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

  1. On mobile, open a channel and move it into a different section (or create/rename/delete a section).
  2. 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.
  3. Return to the app, or check the same section on desktop/another device.
  4. 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-second Timer before 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 if flushPending is 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() watches relaySessionProvider (session connect status) and activeCommunityProvider, both of which commonly change during normal mobile use — e.g. relay_session.dart pauses the session on app background and reconnects on resume (_paused, SessionStatus.reconnecting → connected), which re-triggers build().

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

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của block/buzz

Tất cả issue của block/buzz

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.