My flow misses SharePoint rows because Get items only returns part of the list

I start with a small win: the SharePoint flow runs, and the first batch of items looks right. The emails go out, the updates happen, or the migration begins, so it feels like the automation is finally doing the boring work for me.

Then someone spots the gap. A request is still open, an attachment did not move, or a status report is missing rows that are clearly in the SharePoint list. The run is green, so I do not have a normal failure to debug. I have to prove whether Get items actually returned everything I thought it returned.

By lunchtime I am checking Top Count, pagination, filter query, order by, and the list size. One article says the default is 100, another says use 5,000, another says batch by ID, and the official docs mention a first-5,000 filter limitation. I can make changes, but I am not confident which setting fixes my flow instead of hiding a different missing-row problem.

What I want is a simple retrieval proof before the flow acts: write down the expected row set, get the returned count, test the filter and order, and know when to use pagination or batching. I do not need a clever flow; I need to stop silently skipping rows.