getPage also omits some top-level blocks on a few pages (one page returns none)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github
- Domain
- api
Research direction
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.
Written by the indexing model from the issue text.
Description
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(post2a8e123d92)
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.
- Dominant language
- No language data
- Stars
- 29
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from logseq/db-test
-
Web build on a phone: the fold arrow of an h1/h2 block lies on its bullet, so tapping the bullet folds instead of zooming inPossibly taken @tiensonqin claimed this 2 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 87/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Page titles with `$$`, `$&`, `` $` `` or `$'` change when block refs are resolvedPossibly taken @RaphaelFakhri claimed this 19 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
`#Asset` label is not displayed on asset nodes when `Hide from Node` is disabledPossibly taken @tiensonqin claimed this 22 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Similar issues
-
bot-found bug priority: P3
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
madenvel/KalinkaPlayer#543 ·
-
type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ynput/ayon-usd-resolver#117 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
🚨 Transformers v5.23.0 removes `ProcessingKwargs._defaults` which is used by Qwen-Omni / Gemma3Openquestion
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
modelscope/ms-swift#10538 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
nautechsystems/nautilus_trader#5631 ·
Maintainers usually reply within 1 day