task sync doesn't update the sync.server.client_id value

[martiege]

I recently set up a taskchampion sync server, and wanted to test it out with two of my computers. Initially I set it up with two separate uuids, but when I realised this was not what I wanted to do, I changed the sync.server.client_id field to be the same for both computers.

Inspecting the log of my taskchampion sync server instance, I see that the actual GET calls I receive when I run task sync on the two different instances are the old uuids I initially generated, rather than the new one I generated to be common for both my computers.

Expected behaviour:
Setting the sync.server.client_id field with task config sync.server.client_id **** will change the client id used by task sync.

Current behaviour:
The first, valid, client_id set is used and never updated.

Output of task diag:

task 3.1.0
   Platform: Linux

Compiler
    Version: 13.3.0
       Caps: +stdc +stdc_hosted +LP64 +c8 +i32 +l64 +vp64 +time_t64
 Compliance: C++17

Build Features
      CMake: 3.29.6
    libuuid: libuuid + uuid_unparse_lower
 Build type: Release

Configuration
       File: /home/martin/.config/task/taskrc (found), 186 bytes, mode 100644
       Data: /home/martin/.local/share/task (found), dir, mode 40755
         GC: Enabled
    $EDITOR: /nix/store/xxhkkjhaspx59zvf0infv0imx80fijg2-nixvim/bin/nvim
Hooks
     System: Enabled
   Location: /home/martin/.local/share/task/hooks
     Active: on-add-autoproject (executable) (symlink)
   Inactive:

Tests
   Terminal: 271x54
 Broken ref: Scanned 3 tasks for broken references:
             No broken references found

[martiege]

Wondering if this could be related to #3611?

[martiege]

Some messing around with the config finally caused both computers to request with client_id as all 0-s, which at least allows me to have a working sync...

[martiege]

Could there be some strange behaviour when including files? I initially set everything up using nix and home-manager, which adds its own home-manager-taskrc to .config/task/, which is a symlink (I guess this might also cause some problems?) to a taskrc file created in the nix store, and adds an include to the top of the taskrc (the home-manager-taskrc file is read-only)

[martiege]

Could there be some strange behaviour when including files? I initially set everything up using nix and home-manager, which adds its own home-manager-taskrc to .config/task/, which is a symlink (I guess this might also cause some problems?) to a taskrc file created in the nix store, and adds an include to the top of the taskrc (the home-manager-taskrc file is read-only)

I would guess that this is not the case, when I remove the client_id option from the home-manager-taskrc file, I cannot run task sync due to a missing client_id, so at least at the beginning of this command being run, the home-manager-taskrc file is checked. Also commenting out the include of the home-manager-taskrc file doesn't seem to work.

Is there some caching of the taskrc configuration going on?

[martiege]

Also, task show sync does show the correct values...

[djmitche]

The first, valid, client_id set is used and never updated.

This shouldn't be possible, as the value is read from .taskrc on each execution -- there's nowhere else it could be stored.

It's read from .taskrc here:

taskwarrior/src/commands/CmdSync.cpp

Line 72 in 2e3badb

std::string client_id = Context::getContext().config.get("sync.server.client_id");

and passed to TaskChampion here:

taskwarrior/src/commands/CmdSync.cpp

Lines 103 to 104 in 2e3badb

	replica->sync_to_remote(server_url, tc::uuid_from_string(client_id), encryption_secret,
	avoid_snapshots);

And you can see in the TaskChampion source that there's no "get_cached_client_id" or anything of the sort in the storage API.

[djmitche]

Also, did you provide an all-zeroes client_id at some point? It really shouldn't be defaulting to that..

[martiege]

I never provided an all-zeros client_id, no... But it did change later back to the originally set value. The main issue seems to be the include /home/martin/.config/task/home-manager-taskrc line, as commenting it out and setting the values in the taskrc file works. It really seems like that file causes my issue. Here is the output of running stat on that file, if that can help:

  File: /home/martin/.config/task/home-manager-taskrc -> /nix/store/zyv25byl9prqk1sxdm5nsfdmfx0r1b4a-home-manager-files/.config/task/home-manager-taskrc
  Size: 95              Blocks: 8          IO Block: 4096   symbolic link
Device: 259,2   Inode: 18908526    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/  martin)   Gid: (  100/   users)
Access: 2024-08-31 18:22:31.786276357 +0200
Modify: 2024-08-30 13:07:55.527157183 +0200
Change: 2024-08-30 13:07:55.527157183 +0200
 Birth: 2024-08-30 13:07:55.527157183 +0200

[djmitche]

OK, I'm pretty confused now!

If this is working for you, great -- I'm happy to leave it.

But if not, can you reduce it to one problem and one change that reproduces it? I'm not sure if we're talking about task using a client_id that doesn't appear in any config files, or task using an all-zeroes client_id, or task giving an error due to not finding a client_id.

[martiege]

The closest I can get to reproduce it would be this, though with valid encryption secrets, client UUIDs and server urls:

printf "include /home/martin/.config/task/include-taskrc\n" > ~/.config/task/taskrc
printf "sync.encryption_secret=secret\nsync.server.client_id=uuid1\nsync.server.url=url\n" > include-taskrc
task sync
# the server now logs the correctly a GET /v1/client/get-child-version/uuid1
printf "sync.encryption_secret=secret\nsync.server.client_id=uuid2\nsync.server.url=url\n" > include-taskrc
task sync
# the server still logs GET /v1/client/get-child-version/uuid1

I initially thought something like read / write access to the file was the problem, or the fact it was symlinked, but it seems to occur even when I create a new file, as above.

Could include statements somehow be cached in taskwarrior?

[martiege]

Ok now this is strange, I compiled taskwarrior myself, and added print statements to the CmdSync.cpp file, and while it prints the correct client id, the client id which is actually logged to the server is the wrong one... So it seems like the issue is somewhere between the replica->sync_to_remote call and the server...

[martiege]

Is there a way to enable / get logs from the taskchampion crate?

[djmitche]

Ah, I see the issue -- the client ID does not appear in the URL. See https://gothenburgbitfactory.org/taskchampion/http.html#getchildversion. What you're reading as the client ID is, in fact, the parent version ID. For initial synchronization, that will be the nil UUID (all zeroes).

Is there a way to enable / get logs from the taskchampion crate?

TC uses the logging crate, but does not enable output of that logging. Which is a little weird - I wonder if we removed that? At any rate, #3384 exists to try to get that to work with Taskwarrior.

[martiege]

Ah ok, so does that mean that the id in the url is irrelevant to what the client id, as set in the taskrc, is?

I'll run the same test as I outlined above again, but try to add and complete some tasks in between, to test if everything syncs correctly.

[djmitche]

Yep, totally unrelated

[djmitche]

@martiege what did you figure out?