getPage also omits some top-level blocks on a few pages (one page returns none)

Aperta
  • Qualcosa non va?
#1,457 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github
Ambito
api

Direzione di ricerca

Start with logseq.cli.getPageData and the getPage implementation, then compare its returned blocks with the page’s top-level blocks as counted from db.sqlite. The report provides stable examples and rules out several likely causes, but no distinguishing block attributes or deterministic reproduction recipe. Done means returning every top-level block for the affected pages without changing the correct page entity.

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

Descrizione

What Happened?

On some pages getPage (logseq.cli.getPageData) omits top-level blocks as well — not only the nested ones reported separately. On most pages the response matches the number of top-level blocks exactly; on a few it is short, and on one page it is empty although the page has content.

Counts below are read directly from db.sqlite (blocks whose :block/page is that page, and of those the ones whose :block/parent is the page itself) and compared with the HTTP API response on the same running app:

page blocks on the page top-level blocks blocks returned
journal, Sep 18 2026 92 1 0
journal, Aug 5 2026 55 11 9
journal, Aug 17 2026 78 12 10
journal, Aug 24 2026 72 13 12

All four are stable: repeating the call returns the same short count.

How common it is on this graph: of about 75 pages checked this way, those four were short and the rest matched exactly. All four are 2026 journals. Sampling 18 of the largest journals from each era gave 1 short out of 18 for 2026, and 0 out of 18 for both 2025 and 2024-and-older; a random sample of 25 journals gave 0 short.

The empty one is not a lookup failure: the same call returns the correct entity (title, journal-day, uuid), and it behaves the same whether the page is addressed by uuid or by :block/name. Journals with exactly one top-level block are not generally affected — I sampled five others with one top-level block and 148–250 blocks each, and all returned 1.

What I could rule out:

  • Not the number of top-level blocks. Pages with 1, 2 and 13 top-level blocks all return the full count elsewhere.
  • Not :logseq.property/used-template. The single top-level block on the empty page carries it, and that property is :hide? true, which made it the obvious suspect. But pages whose top-level blocks also carry it return them normally (1→1, 2→2, 11→11), so that is not the rule.

I could not identify what distinguishes the blocks that are dropped. Comparing the attribute sets of a dropped block and a returned one shows no difference beyond that template property.

Reproduce the Bug

I have no deterministic recipe — this is an observation on a real graph, where it is stable and repeatable on the affected pages across calls and across both addressing modes. The method is the structural comparison above: read the block counts out of db.sqlite and compare them with what the API returns for the same page.

Expected Behavior

getPage returns every top-level block of the page.

Desktop Platform
  • OS: Windows 11
  • Graph type: DB graph
  • Build: self-built from master (post 2a8e123d92)
Additional Context

Filed separately from the missing-:block/children issue because that one has a clear cause in get-page-data and this one does not — fixing the nesting will not make these blocks appear.

The graph holds clinical records, so I cannot share page content, but I can run any structural query against it that would help narrow this down.

Lingua principale
Nessun dato sulla lingua
Stelle
29
Fork
2
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 logseq/db-test

Tutte le issue di logseq/db-test

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.