Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message 'No todos in this file' after a task has been completed #692

Closed
mdbdb opened this issue Mar 27, 2024 · 13 comments
Closed

Message 'No todos in this file' after a task has been completed #692

mdbdb opened this issue Mar 27, 2024 · 13 comments
Labels
bug Something isn't working

Comments

@mdbdb
Copy link

mdbdb commented Mar 27, 2024

Bug Report

App Version: 2.0.12

Platform: Linux

Installation Method: App Store (Flatpak)

Expected Behavior:
If I mark a task as completed, it should disappear from the list - all other (uncompleted) tasks should remain visible.

Actual Behavior:
I mark a task as completed, then all tasks disappear from the list and the message 'No todos in this file' is displayed.
I can now close the file and reopen it - so all uncompleted tasks are back. Or I can just change the window size and all tasks will reappear.

I noticed this behavior for the first time after updating to version 2.0.12. And the error really occurs every time I check off a task.

Steps to Reproduce:

  1. open the app
  2. mark a task as completed
  3. --> List empty, message 'No todos in this file'
  4. change the window size
  5. unfinished tasks are displayed

Screenshots:

  1. before I have marked a task as completed
    sleek-1
  2. after I have marked a task as completed
    sleek-2
  3. after I have changed the size of the window
    sleek-3
@ransome1
Copy link
Owner

@mdbdb is there by any chance some file sync happening in the background, for example Synchting, Dropbox, Google Drive and so forth?

@ransome1 ransome1 moved this from Backlog to In Progress in sleek 2.x Mar 27, 2024
@ransome1
Copy link
Owner

@mdbdb @TriggerDingus in 2.0.12 we were tweaking the filewatcher settings a bit, because some had issues with sleek and file syncing applications. Actually this has been a constant pain for years now. We also introduced new settings to tackle difficulties, which could arise in environment, where there is file syncing involved.

@aisbergde @RobLW @42web-ch this is also a heads up for you guys. In the next pre-release (2.0.13-rc.2) I will revert the default settings of the filewatcher to pre 2.0.12 since it seemed to worked better for the majority of users. 2.0.12 has only just been released and is already producing bug reports connected to the change.

I will furthermore remove the 3 settings we introduced over at #676.

Instead I will introduce 1 new setting named chokidarOptions. This new setting represents the chokidar options object as described here: https://github.com/paulmillr/chokidar?tab=readme-ov-file#persistence

Like this you will have all of Chokidar's options available and can adjust the filewatcher precisely to your environment. Since you might have already adapted to the 3 new options you will now need to apply your changes using the chokidar syntax. For example:

{
usePolling: false,
interval: 100,
atomic: true
}

Chokidar has many more options, which can help figuring out a working setting for your particular environment.

ransome1 added a commit that referenced this issue Mar 27, 2024
… reverting default filewatcher configuration to pre 2.0.12
@ransome1
Copy link
Owner

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

@TriggerDingus
Copy link

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

I completed several tasks with the AppImage and no issues so far. I'll keep using it this afternoon and report if it happens again.

@GaloisGecko
Copy link

GaloisGecko commented Mar 27, 2024

I have the exact same issue. I tried it with a file that is not synced to any other storage. But I observed that the issue occurs if and only if the task is recurring: If I complete the following task

2024-03-27 test  rec:+1d due:2024-03-27

the UI will show no tasks any more, but if I complete

2024-03-27 test due:2024-03-27

all remaining open tasks will stay on the UI as desired.
Maybe it helps to narrow down the issue.

@ransome1
Copy link
Owner

@GaloisGecko

the UI will show no tasks any more, but if I complete

What exactly does the UI show?

And how do your filter settings look like in the drawer?

@GaloisGecko
Copy link

GaloisGecko commented Mar 27, 2024

This is the UI including filter settings before I complete the recurring task:

Before

And after I complete the recurring task, it looks like this:

After

If the task would not be recurring, it would vanish, but the other task would remain on the UI.

@ransome1
Copy link
Owner

Is this the latest pre-release (2.0.13-rc.2) or 2.0.12? If it is the latter, does the same happen with the pre-release as well? There is an AppImage in that release for a quick glance.

@GaloisGecko
Copy link

GaloisGecko commented Mar 27, 2024

I am still on 2.0.12, sorry for that.
Update: Now I checked with the AppImage for 2.0.13-rc.2 and it works fine! The tasks do not vanish any more!

@mdbdb
Copy link
Author

mdbdb commented Mar 28, 2024

@mdbdb @TriggerDingus before you start wrapping your head around all those Chokidar options, can I ask you to check out this pre-release and tell me if the issue still occurs? https://github.com/ransome1/sleek/releases/tag/v2.0.13-rc.2

If the config migration worked, it should regress to the behavior of sleek 2.0.11, where I understand you did not face these issues.

@aisbergde @RobLW @42web-ch you're invited to check the new option and let me know if this works for you.

I just marked some of my tasks as done with version 2.0.13-rc.2 under the same conditions as before (todo.txt is synchronized via Syncthing).

➡️ The error no longer occurs!

@ransome1
Copy link
Owner

@mdbdb has been released with 2.0.13. If it occurs again, check back in here. We now have several ways to adjust to your environment with these settings.

@github-project-automation github-project-automation bot moved this from In Progress to Done in sleek 2.x Mar 28, 2024
@42web-ch
Copy link

@ransome1 Hi, thanks for the update. I am switched from debian to arch on my work pc. All works fine on the new setup!

@RobLW
Copy link

RobLW commented Apr 25, 2024

Apologies I've been neglecting the app recently so not noticed changes/issues.

I've just updated Fedora from 39 to 40. The issue took place then. When I opened the app and laid my mouse over the tabs, I noticed that it was referring to a location that I think was for temporary files.(sorry I forgot to make actual note or screenshot).

Thinking about it now, I'm wondering does the app use a temporary file while open, and occasionally writes this back to the actual todo files?.
If this is the case then when we reboot without closing down the app (which is always the case for me) the system will wipe the temp files and the app loads again expecting to find those files rather than loading the todo files in my home dir.? Just a thought.

EDIT:
ah just run it from the command line and noticed it does:
Watching new file: /run/user/1000/doc/4f9257d5/todo_2024_02.txt
Which I guess is the temp file I'm talking about above.

I'm using 2.0.13 flatpak.

On a side note I also saw this error when starting, even though the file is there with setuid on it.
[2:0425/122434.527260:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

No branches or pull requests

6 participants