Journal queries are wrong after start up

I have 4 queries:

Summary
[{:title "IN PROGRESS"
    :query [:find (pull ?h [*])
            :where
            [?h :block/marker ?marker]
            [(contains? #{"NOW" "DOING"} ?marker)]]
    :result-transform (fn [result]
                        (sort-by (fn [h]
                                   (get h :block/priority "Z")) result))
    :breadcrumb-show? false
    :collapsed? false}

    {:title "TODAY"
    :query [:find (pull ?block [*])
          :in $ ?td
          :where
          [?block :block/marker ?marker]
          [(contains? #{"TODO" "LATER"} ?marker)]
          (or
            [?block :block/scheduled ?d]
            [?block :block/deadline ?d])
          [(= ?d ?td)]]
    :inputs [:today]
    :result-transform (fn [result]
       (sort-by (fn [h] (get h :block/content)) result))
    :breadcrumb-show? false
    :collapsed? false}

   {:title  "NEXT"
    :query [:find (pull ?block [*])
          :in $ ?start ?next
          :where
          [?block :block/marker ?marker]
          [(contains? #{"TODO" "LATER"} ?marker)]
          (or
            [?block :block/scheduled ?d]
            [?block :block/deadline ?d])
          [(>= ?d ?start)]
          [(<= ?d ?next)]]
    :inputs [:1d-after :14d-after]
    :result-transform (fn [result]
       (sort-by (fn [h]
             (or (get h :block/scheduled) (get h :block/deadline))) result))
    :breadcrumb-show? false
    :collapsed? false}

    {:title "OVERDUE"
    :query [:find (pull ?block [*])
          :in $ ?start ?next
          :where
          [?block :block/marker ?marker]
          [(contains? #{"TODO" "LATER"} ?marker)]
          (or
            [?block :block/scheduled ?d]
            [?block :block/deadline ?d])
          [(>= ?d ?start)]
          [(<= ?d ?next)]]
    :inputs [:28d-before :1d-before]
    :result-transform (fn [result]
       (sort-by (fn [h]
             (or (get h :block/scheduled) (get h :block/deadline))) result))
    :breadcrumb-show? false
    :collapsed? false}]}```

And I have multiple tasks that repeat daily of every few days, which I’m running for a few months now. After starting logseq displays most of the task under “Overdue” query. Only after changing page and going back to the Journal page, they are displayed correctly (so under “Today” or “Next”).

Does this happen every time?
I copied your queries and scheduled a bunch of tasks. I see correct behavior on start up.
I’ll see what will happen tomorrow.

Thanks for checking, you’ve prodded me to have a closer look as well.

I think this is related to overdue tasks/query. For example I had one task still scheduled to 16th Oct, and today when I’ve opened LS all tasks were listed under “Overdue” query (except those in Doing state which were correctly under “In progress” query) with scheduled date 16th Oct (all are actually scheduled for today or later). Once I’ve marked the task as done, everything is listed correctly after startup. Unfortunately I can’t break things again, changing task’s scheduled to 16 Oct, restoring it to pre-edit state, or playing with the logbook data directly doesn’t break it.

Another possibility is that some of the data in logbook is messed up, e.g.:
State "" from "TODO" [2023-07-14 Fri 21:54]
Maybe due to some plugins I’ve tried. I’ve also did manual rescheduling in the past w/o changing the day of the week, which breaks the task (but I likely fixed that fully).

But either way something different has to happen at startup in query execution, in comparison to query execution under page refresh.

this happens a lot, more often on my home graph (with more data) than on my work one.

Oh that is really weird.
I only ever ran into issues of queries not actually refreshing yet on start up.
But that would pose the opposite problem ie. the task would be in today instead of overdue.
If it’s hard to reproduce it is hard to figure out what goes wrong.
I’m definitely not a programmer though lol. I just do queries :sweat_smile:
I didn’t notice anything wrong with those.

I had some issues w/ queries not refreshing as well (e.g. after marking a task done).

Queries displayed incorrectly for me today as well, but only on the first LS opening after the machine start-up. And it doesn’t look like yesterday’s explanation fitted. On further LS opening all was fine (in the past after each LS startup queries content was incorrect).

I’ll come back to this thread if I see anything that makes sense.

Make sure you are on the latest Logseq version. I know there was an old(er) version that had issues with queries not properly refreshing.

Update: couldn’t figure it out yet. I’ve done a few things, including disabling some plugins, removing all LOGBOOK data. I’ve also set up my main graph on a second machine (with a different OS, but still Linux), I think the problem occurred there immediately after I’ve cloned the data, but I was busy with configuring stuff, so I’m not super sure about it. I should be using that other machine from time to time, so at some point I might at least be able to confirm if the same issue happen there as well.

But at this point I think it’s something with the config file, perhaps the queries themselves.

It has suddenly fixed itself about a week ago, without any clear cause.

1 Like

That’s weird. But glad to hear it is fixed!

This issue has came back shorty after my last post. It’s clearly showing tasks from bak files, but why I’ve no clue. I thought that this is caused by logseq not using the actual files because of some blocking activity on the disk (which there is a lot after I start, and logseq auto-starts). However I came back to using the app more on my Windows machine and there is the same issue, despite opening the app manually when there is no flurry of disk activity.

So, since it doesn’t seem to be a common problem, it must be either queries or some setting I’m using on both machines. But I don’t see anything suspicious in either.

I’ll come back with more exciting news when there are new developments. Stay tuned folks.

Sorry to hear you’re still having this issue. I have no idea what it could be. In all my use of Logseq I have not experienced this.