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

Open
  • Is something wrong?
#1,512 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
clojure
Domain
backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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!)
Dominant language
No language data
Stars
29
Forks
2
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from logseq/db-test

All issues in logseq/db-test

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.