Browse: keep a proven last page when the record count arrives or shrinks, not only when it's unchanged

Aperta Adatta ai principianti
#1,963 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend

Direzione di ricerca

Inizia dalla verifica della prova dell'ultima pagina in DatabaseTableView.tsx, dove l'ultima pagina memorizzata viene scartata ogni volta che il numero di record differisce dal conteggio per cui era stata provata. Leggi come Next usa quella prova, poi aggiungi test per i tre casi di conteggio: primo accesso, crescita e riduzione. È completato quando la prova viene mantenuta al primo accesso e in caso di riduzione, scartata in caso di crescita, e ogni caso è coperto da un test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What happens

After #1958, Browse remembers that a page is the last one only while the table's record count is the same as when that was proven. A count that moves lets Next probe past it again, which is what fixes #1940.

The rule is strict equality, so a remembered last page is also dropped when nothing new could be past it:

  • The count first arrives. The proof was made before the count was known, and the count then loads.
  • The count shrinks. Records were deleted, so a page that was last is still last, or now past the end.

Either way the next step costs one extra probe of the page after it. That probe comes back empty and proves the last page again. Nothing is shown wrongly and Next still works, so it's one wasted read, not a bug the user sees.

Possible improvement

Only retire the proof when the count grows: keep it when the count first arrives, or when it shrinks. It's a small change to the proof check in DatabaseTableView.tsx, and needs a test for each of the three cases.

Low priority: the cost is one read per step after a deletion or an initial count load.

Review-Deferral: a3b75b0e1d3e87f1 severity=nit category=correctness

Raised by the cross-model review of #1958 (#1940).

🤖 Generated by Anthropic Claude Code (Claude Opus 5.5); posted via @dawsontoth.

Lingua principale
TypeScript
Stelle
5
Fork
4
Merge medio
1g 20h
PR unite (30g)
140

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/studio

Tutte le issue di HarperFast/studio

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.