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

Aperta
  • Qualcosa non va?
#1,512 3 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
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
clojure
Ambito
backend

Direzione di ricerca

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.

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

Descrizione

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!)
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.