Perhaps you try running one more variation?

Your second query groups by date_extraction only which is a business column, so it can't tell us which commit those rows came from. Seeing the 2026-04-09 rows doesn't yet prove the result contains version 25. It could equally mean a commit at or after version 26 wrote rows carrying that older date. The same query with the version column visible would settle it:

```sql
SELECT _commit_version, _change_type, date_extraction, count(*) AS n
FROM table_changes('duh_dev_bronze.sibl.cup_rate', 26)
GROUP BY ALL
ORDER BY 1;
```

If the 04-09 rows come back with a _commit_version of 26 or higher, the feed is fine and something wrote that older date again after your first check. Worth asking then is whether the source file was re-uploaded or modified (a stream with allowOverwrites picks it up again), whether a backfill ran, or whether the streaming table was full refreshed, which rewrites every row under new versions and would also explain your original observation that after some time "all versions" seem to come back.