getPage also omits some top-level blocks on a few pages (one page returns none)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- github
- Lĩnh vực
- api
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 29
- Fork
- 2
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của 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 inCó thể đã có người làm @tiensonqin đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 87/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
-
Page titles with `$$`, `$&`, `` $` `` or `$'` change when block refs are resolvedCó thể đã có người làm @RaphaelFakhri đã nhận 19 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
`#Asset` label is not displayed on asset nodes when `Hide from Node` is disabledCó thể đã có người làm @tiensonqin đã nhận 22 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Tất cả issue của logseq/db-test
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Azure/azure-functions-nodejs-extensions#180 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
jasonacox/pypowerwall#472 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
sebastienros/jint#4531 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
iso-bmff: add IsoBoxReadView.readUint64 and IsoBoxWriteView.writeUint64 for exact 64-bit fieldsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
streaming-video-technology-alliance/common-media-library#611 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: DoubleMLRDDData accepts a score_col that is no data column (as in its docstring example); the running variable then becomes a covariate and RDFlex failsCó thể đã có người làm @vrjdev đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
DoubleML/doubleml-for-py#455 ·
Maintainer thường phản hồi trong vòng 1 ngày