Files
buzz/mobile/test
ravarora2 7b3c2f95f2 fix(mobile): bound notices to loaded message history (#9062)
## Summary

Mobile reads system notices older than its loaded message window, even
though those notices cannot yet appear. Bound notice reads by the oldest
loaded message's timestamp to avoid fetching history outside the loaded
time range.

A short or empty bounded response finishes that time range, rather than
all notice history. Preserve the full boundary second, resume when older
message pages load, and keep notices before the first message available
at the start of history. Enforce the 2,000-notice cap before fetching
reactions. Reuse cached reactions and deletions when older pages reveal
their notices.

For channels with fewer than 500 notices, scrolling back can now require
one bounded notice read per older message page. Previously, one
unbounded read covered the channel.

### Related issue

Related: #8962, which changed how mobile loads and displays membership
notices. No duplicate notice-bound PR found in the open mobile-notice
title search.

### Testing

Mutation checks: removing the production `since` argument or restoring
the old unconditional history-end flag each made all four notice-range
cases fail. Command: `cd mobile && flutter test --no-pub
--dart-define=BUZZ_PUSH_GATEWAY_URL=https://push.example
test/features/channels/channel_notices_journey_test.dart --name 'notice
ranges'`.

Replacing the captured message cursor with a fabricated maximum ID also
fails the empty-range progress regression. Command: `cd mobile &&
flutter test --no-pub
--dart-define=BUZZ_PUSH_GATEWAY_URL=https://push.example
test/features/channels/channel_messages_provider_test.dart --name 'an
empty notice range'`.

A read-only prepared-query check on local Postgres 17.10 used a
representative kind-40099 query. It held 22 event-related relation locks
with `force_custom_plan` and 99 with `force_generic_plan`. The generic
plan pruned seven of eight partitions during execution but retained the
broader locks. These results do not establish lock reduction or
throughput improvement under the relay's actual cached-plan workload; a
relay load test remains pending.

Native app scrolling against a live relay and human confirmation remain
pending.

For the device check, run `just mobile-dev` on a host with an iOS
Simulator runtime. Connect to a local test relay and open a channel with
more than 150 messages and interleaved topic notices. Scroll back
through at least three message pages, then to the start. Check that
visible notices remain in order and appear once. Disconnect during a
page read, reconnect, and continue scrolling to check recovery.

Generated with Codex

---------

Signed-off-by: BuzzPRReviewAssistant1 <a581a7e8115222acdc32ffb14bfce55d48c24478d98e155f8eba126b69b83c7b@buzz.block.builderlab.xyz>
Co-authored-by: BuzzPRReviewAssistant1 <a581a7e8115222acdc32ffb14bfce55d48c24478d98e155f8eba126b69b83c7b@buzz.block.builderlab.xyz>
2026-11-04 16:26:35 -05:00
..