Found while implementing #22 (cursor pagination). Pre-existing, unrelated to that change, so filed
rather than fixed there.
The bug
DefaultMessagesRepository.createMessage inserts the new post at maxFeedOrder() - 1.
The feed sorts by feedOrder ASC. With a cached feed of more than two rows, maxFeedOrder() - 1
is not smaller than every other row's order — so the new message lands somewhere in the middle
of the feed instead of at the top.
Why the tests do not catch it
The existing coverage exercises a single-row feed, where maxFeedOrder() - 1 happens to be
correct. The bug only shows up with three or more cached rows.
Fix
Add a minFeedOrder() query to MessageDao and insert at minFeedOrder() - 1. Extend the test to
a feed of at least three rows so the regression is actually covered.
Reported by the agent implementing #22; left out of that PR because it sits in composer code that
#19 and #20 will be touching.
Found while implementing #22 (cursor pagination). Pre-existing, unrelated to that change, so filed
rather than fixed there.
The bug
DefaultMessagesRepository.createMessageinserts the new post atmaxFeedOrder() - 1.The feed sorts by
feedOrder ASC. With a cached feed of more than two rows,maxFeedOrder() - 1is not smaller than every other row's order — so the new message lands somewhere in the middle
of the feed instead of at the top.
Why the tests do not catch it
The existing coverage exercises a single-row feed, where
maxFeedOrder() - 1happens to becorrect. The bug only shows up with three or more cached rows.
Fix
Add a
minFeedOrder()query toMessageDaoand insert atminFeedOrder() - 1. Extend the test toa feed of at least three rows so the regression is actually covered.
Reported by the agent implementing #22; left out of that PR because it sits in composer code that
#19 and #20 will be touching.