Page MenuHomePhabricator

Fix an issue where paginating notifications could fail a GROUP BY test
ClosedPublic

Authored by epriestley on Feb 26 2021, 6:45 PM.
Tags
None
Referenced Files
F18934995: D21577.diff
Mon, Nov 10, 5:34 PM
F18855005: D21577.id.diff
Sat, Nov 1, 2:08 AM
F18853208: D21577.diff
Fri, Oct 31, 3:00 PM
F18816582: D21577.id51365.diff
Oct 21 2025, 7:52 AM
F18770084: D21577.id51365.diff
Oct 8 2025, 10:38 AM
F18693902: D21577.id.diff
Sep 27 2025, 2:05 AM
F18687691: D21577.diff
Sep 26 2025, 3:23 PM
F18674110: D21577.id51377.diff
Sep 25 2025, 1:19 PM
Subscribers
None

Details

Summary

Ref T13623. When paginating notifications, we may currently construct a query which:

  • loads from non-unique rows; and
  • returns multiple results.

In particular, chronologicalKey isn't unique across the whole table (only for a given viewer). We can get away with this because no user-facing view of notifications is truly "every notification for every viewer" today.

One fix would be to implicitly force the paging query to include withUserPHIDs(viewerPHID), but puruse a slightly more general fix:

  • Load only unique stories.
  • Explictly limit the pagination subquery to one result.
Test Plan
  • Set page size to 1, inserted duplicate notifications of all stories for another user, clicked "Next", got the GROUP BY error.
  • Applied the "only load unique stories" part of the change, got a "expected one row" error instead.
  • Applied the "limit 1" part of the change, got a second page of notifications.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable