docs(notifications): describe the cold-start floor as what it is

The comment called it a backward-paging boundary that asks for everything
older than the feed's oldest card. It is neither: backward paging lives in
AccountNotificationsHistoryEoseManager, and `since` means newer-than, so
it floors the query at the depth the feed already reaches instead of
asking all-time again. It is also read only until a relay has an EOSE.

Records that it is always null for an account with no UI, since nothing
fills that feed — which is what makes the field inert on a headless path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Vitor Pamplona
2026-07-30 22:58:05 -04:00
co-authored by Claude Opus 5
parent 3f4723437e
commit 54afbf95e7
@@ -49,9 +49,13 @@ class AccountNotificationsEoseFromInboxRelaysManager(
key: AccountQueryState,
since: SincePerRelayMap?,
): List<RelayBasedFilter> {
// Backward-paging boundary: once the feed has filled a page, ask for everything older than
// its oldest card. It stays null until then — see the note on the missing week floor below,
// which is what let it stay null forever on a quiet inbox.
// A cold-start floor, NOT paging — backward paging lives in
// [AccountNotificationsHistoryEoseManager]. Read only when a relay has no EOSE yet; once it
// does, the EOSE time wins and this is never consulted.
//
// `since` means *newer than*, so this floors the query at the depth the feed already reaches
// rather than asking all-time again. It stays null until the feed holds a full page — and is
// therefore always null for an account with no UI, since nothing fills that feed.
val pagingBoundary = key.feedContentStates.notifications.lastNoteCreatedAtIfFilled()
val inbox =