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

Abierto
  • ¿Algo no está bien?
#1,512 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
clojure
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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!)
Lenguaje dominante
Sin datos de lenguaje
Estrellas
29
Forks
2
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de logseq/db-test

Todos los issues de logseq/db-test

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.