Fix search pagination in list messages

[c-julin]

Summary

Fixes an issue where searching/filtering messages while on page 2+ would show no results because the pagination index exceeded the filtered result set.

Changes

• Bound pageIndex to valid range based on filtered results count
• Preserves original pageIndex state so clearing the search returns to the same page

Test plan

• Navigate to a topic with enough messages to have multiple pages
• Go to page 2
• Use the "Filter table content" search box to filter messages
• Verify results are displayed (previously showed empty)
• Clear the search and verify you return to page 2

[jvorcak]

isn't there some util function for this already?, if not shouldn't there be some?

[malinskibeniamin]

@claude review

[claude]

Claude finished @malinskibeniamin's task in 1m 23s —— View job

---

Code Review

Tasks

• Read repository guidelines (CLAUDE.md)
• Read the changed file and understand the implementation
• Analyze code changes for correctness and best practices
• Provide comprehensive review feedback

---

Review Summary

The fix correctly addresses the pagination bug where searching messages while on page 2+ would show no results. The logic is sound and the implementation preserves the user's original page index when clearing the search.

Detailed Feedback

✅ What's Good

• Correct Logic: The bounded index calculation properly prevents pageIndex from exceeding the filtered results
• User Experience: Preserving the original pageIndex so users return to their previous page after clearing search is a nice touch
• Minimal Change: The fix is focused and doesn't over-engineer the solution

💡 Suggestions for Improvement

1. Use the existing clamp utility (addressing @jvorcak's review comment)

The codebase has a clamp method available via Number.prototype.clamp() (defined in frontend/src/utils/number-extensions.ts:33-41). This is already used in other parts of the codebase:

• frontend/src/components/pages/reassign-partitions/components/bandwidth-slider.tsx:60
• frontend/src/components/pages/reassign-partitions/components/active-reassignments.tsx:705

Current implementation:

const totalPages = Math.max(1, Math.ceil(filteredMessages.length / pageSize));
const boundedPageIndex = Math.min(pageIndex, totalPages - 1);

Could be simplified to:

const totalPages = Math.max(1, Math.ceil(filteredMessages.length / pageSize));
const boundedPageIndex = pageIndex.clamp(0, totalPages - 1);

This would:

• Use the established pattern in the codebase
• Also handle the edge case where pageIndex might be negative (though unlikely)
• Be more readable and concise

2. Consider edge case testing

While the current logic handles the primary use case, consider testing these scenarios:

• Empty filtered results (filteredMessages.length === 0)
• Negative page indices (though parseAsInteger.withDefault(0) likely prevents this)
• Very large page indices

The current code with Math.max(1, Math.ceil(...)) ensures totalPages is at least 1, which prevents issues when filteredMessages.length === 0. Good defensive programming!

📝 Minor Notes

• The inline comment on line 643 is helpful and explains the "why" well
• The variable names boundedPageIndex and totalPages are clear and descriptive

Verdict

This is a solid fix that correctly addresses the issue. The only actionable improvement would be to use the .clamp() utility for consistency with the rest of the codebase, per @jvorcak's suggestion.

---