Completing a repeating task through the CLI moves Scheduled but leaves `:block/refs` on the old journal day

Đang mở
  • Có gì không ổn?
#1,512 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
clojure
Lĩnh vực
backend

Hướng nghiên cứu

Start with compute-extra-tx-data in src/main/frontend/worker/pipeline.cljs, where the issue says the repeating-task reschedule is added, then trace how transact-pipeline rebuilds refs from tx-report*. Compare this CLI reschedule path with setting Scheduled directly and with the app path described in the issue. Done when completing a repeating task updates :block/refs to the journal page for its new Scheduled date and removes the old date.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Search first
  • I searched and no similar issues were found
What Happened?

When logseq upsert task --id <id> --status done completes a repeating task, the repeat command moves Scheduled to the next occurrence and resets the status, but the block's :block/refs are not rebuilt. They keep the journal page of the old date and never get the new one. The task stays in the Linked References of the day it was completed instead of the day it is now scheduled for, and every query that joins on :block/refs sees the old date.

The refs follow as soon as the block's content is saved again (upsert block --id <id> --content '<same title>').

Setting Scheduled directly with upsert block --id <id> --update-properties '{:logseq.property/scheduled <ms>}' does update the journal ref. Only the reschedule that the repeat command adds is missed.

Unlike #1399, this is not the multi-op batch gap: the repro sets one property per call, and --status done is a single batch-set-property op. It is also not limited to a CLI-owned worker. The repro runs on one, and I first saw it on a graph whose worker the desktop app owns (owner-source electron). In that graph, the repeating tasks I complete in the desktop or mobile app have refs that match their new Scheduled date. The only two with a stale ref are the two that a script completes through the CLI.

Reproduce the Bug
G=refs-repeat-repro
logseq graph create --graph $G
TODAY=$(date -d 'today 00:00' +%s)000
choice() { logseq query --graph $G --output json --query "[:find ?v . :where [?v :block/closed-value-property ?p] [?p :db/ident $1] [?v :block/title \"$2\"]]" | jq .data.result; }
WEEK=$(choice :logseq.property.repeat/recur-unit Week)
TYPE=$(choice :logseq.property.repeat/repeat-type "Advance from scheduled")
ID=$(logseq upsert block --graph $G --target-page Home --content "weekly chore" --output json | jq '.data.result[0]')
logseq upsert task --graph $G --id $ID --status todo
for kv in ":logseq.property/scheduled $TODAY" ":logseq.property.repeat/repeated? true" \
  ":logseq.property.repeat/recur-frequency 1" ":logseq.property.repeat/recur-unit $WEEK" \
  ":logseq.property.repeat/repeat-type $TYPE" ":logseq.property.repeat/temporal-property :logseq.property/scheduled"; do
  logseq upsert block --graph $G --id $ID --update-properties "{$kv}"
done
refs() { logseq query --graph $G --query "[:find [?jd ...] :where [$ID :block/refs ?r] [?r :block/journal-day ?jd]]"; }

logseq upsert task  --graph $G --id $ID --status done;           refs   # 2
logseq upsert block --graph $G --id $ID --content "weekly chore"; refs  # 3
logseq upsert task  --graph $G --id $ID --status done;           refs   # 4
logseq upsert block --graph $G --id $ID --content "weekly chore"; refs  # 5

Result, run on 08-11-2026:

Step Scheduled Journal days in :block/refs
1 set up 08-11-2026 (none: no journal page for that day yet)
2 --status done 15-11-2026 (none), although the reschedule created the 15-11 journal page
3 content re-saved 15-11-2026 15-11-2026
4 --status done 22-11-2026 15-11-2026 (stale)
5 content re-saved 22-11-2026 22-11-2026
Expected Behavior

After the repeat command reschedules the task, :block/refs holds the journal of the new Scheduled date and no longer the old one, the same as when Scheduled is set directly.

Screenshots

No response

Files

No response

Browser, Desktop or Mobile Platform Information

Linux, logseq --version: revision 533ac43, build time 2026-10-07T14:07:14Z.

Additional Context

Related: #1248, where a later pipeline step also missed what the repeating-task reschedule added (there the tag template, here the refs).

The reschedule comes from commands/run-commands inside compute-extra-tx-data (src/main/frontend/worker/pipeline.cljs), and transact-pipeline rebuilds refs on tx-report* afterwards, so I expected the new date to be picked up. I did not trace why it isn't.

Found with the help of an AI coding assistant driving the CLI. I noticed the stale reference in the app and confirmed that tasks completed in the app are not affected.

Are you willing to submit a PR? If you know how to fix the bug.
  • I'm willing to submit a PR (Thank you!)
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
29
Fork
2
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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của logseq/db-test

Tất cả issue của logseq/db-test

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.