Fixes#21355
## Problem
On a Record Board (Kanban) view, columns that contain more than 20
records stop loading at exactly 20. The initial query loads the first
page, one automatic fetch brings the column to 20, and then the loading
placeholder at the bottom of the column **spins forever** — scrolling
all the way down triggers no further requests. Every column is
permanently capped at `2 * RECORD_BOARD_QUERY_PAGE_SIZE` (20) records.
### Steps to reproduce
1. Open any object in board view, grouped by a field where at least one
group has > 20 matching records.
2. Wait for the board to load — the first 20 cards in the large column
appear.
3. Scroll that column to the bottom.
**Expected:** more cards load as you approach the bottom, until the
column is exhausted.
**Actual:** the placeholder stays forever; no additional group-by
request is fired.
## Root cause
An **edge-triggered consumer reading a level signal that is stuck
high.**
The fetch-more trigger (`RecordBoardFetchMoreInViewTriggerComponent`) is
an `IntersectionObserver` sentinel that writes its `inView` state into
the board-level `recordBoardShouldFetchMoreComponentState`. Its
`rootMargin` is:
```ts
const rootMargin = `${estimatedCardHeight * RECORD_BOARD_QUERY_PAGE_SIZE * 2}px`;
```
With `estimatedCardHeight ≈ 130px` and `RECORD_BOARD_QUERY_PAGE_SIZE =
10`, that's ~2600px — roughly two pages, i.e. as tall as the entire
already-loaded board. So the sentinel reports `inView = true` across the
whole loaded board, and the boolean **latches `true` after the first
auto-fetch and never toggles back**.
The consumer in `RecordBoardQueryEffect` only reacts to the **false→true
edge** of that boolean, and `triggerRecordBoardFetchMore` is a stable
`useCallback`. Once the boolean is stuck `true` and the dependency array
stops changing, the effect never re-runs — so it fetches exactly once.
The signal is *level* ("the bottom is in view, keep loading") but it's
consumed as an *edge* ("the bottom just appeared, load once"), and the
oversized `rootMargin` guarantees the level is permanently high so the
single edge never repeats.
The large `rootMargin` is intentional prefetch buffering and is not the
bug; the consumer simply needs to keep paging while the signal is high.
## Fix
Make the consumer **re-arm** the trigger after every page that actually
returned records:
1. `useTriggerRecordBoardFetchMore` now returns a `boolean` — `true`
only once at least one column received records this round, `false` on
every early-exit / empty result.
2. `RecordBoardQueryEffect` resets
`recordBoardShouldFetchMoreComponentState` to `false` after a
**productive** fetch. The sentinel is still inside the inflated
`rootMargin`, so the observer immediately re-asserts `true`, which
re-runs the effect and fetches the next page.
The loop terminates naturally and never spins:
- **Buffer filled** — enough cards load that the sentinel finally leaves
the `rootMargin` → observer reports `false` → loop stops. As the user
scrolls, it re-arms (normal infinite scroll).
- **Columns exhausted** — `triggerRecordBoardFetchMore` returns `false`
(per-column `shouldFetchMore` flags already get set `false` when a page
returns `< PAGE_SIZE`), so the boolean is not reset and no further fetch
fires — no busy-loop on a fully-loaded board.
The existing `recordBoardIsFetchingMore` re-entrancy guard prevents any
overlapping/double fetch during the round-trip.
## Test
- `npx nx typecheck twenty-front` → passes
- `npx nx lint twenty-front` (oxlint --type-aware + oxfmt) → 0 warnings,
0 errors, formatting clean
- Manually verified on a board with columns of 38 and 74 records:
pre-fix both froze at 20; post-fix they page to completion on scroll,
and a fully-loaded board issues no extra requests.
## Notes / alternatives considered
- **Shrinking `rootMargin`** would mask the bug for tall boards but
defeat the intended prefetch buffering and reintroduce it whenever the
buffer is smaller than the loaded content. The level/edge mismatch is
the real defect.
- **Moving the loop into the trigger component** was rejected — it only
knows `inView`, not whether a fetch was productive or whether columns
are exhausted, so self-looping there would increase coupling. The query
effect is the right owner of fetch orchestration.
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Félix Malfait <felix@twenty.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
Marc Bickel
5d0a4b8db4