Change:
syncthing = handleTest ./syncthing.nix {}; syncthing-no-settings = handleTest ./syncthing-no-settings.nix {}; syncthing-init = handleTest ./syncthing-init.nix {}; <ins> syncthing-many-devices = handleTest ./syncthing-many-devices.nix {}; </ins> syncthing-relay = handleTest ./syncthing-relay.nix {}; systemd = handleTest ./systemd.nix {}; systemd-analyze = handleTest ./systemd-analyze.nix {};

Discussion:
If you add enough (minimum number I haven't searched for) settings, then the script of applying these settings via api will not be able to execute completely and curl will generate "CSRF Error" error, this happens because syncthing resets api key after applying a certain number of settings Steps to reproduce the behavior: services.syncthing several devices and options logs of syncthing-init.service, there will be errors syncthing-init.service will execute entirely with no errors and will apply the entire configuration without errors ! I made a vm with the minimal configuration at which the error is reproduced I used nixpkgs commit Config for vm - Steps to reproduce nixpkgs - vm config - vm - vm, login as with password "CSRF Error" and parse error from jq Also during testing I managed to fix this by parsing the api key before each curl call, this helps but looks like a dirty solution <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Hmm indeed we recently changed a few details in the script in: I tried to write a nixos test to test some of these issues, and I experienced numerous other bugs, and I sort of reproduced the issue as well. I Reverted In: And reopened: cc .
I have this issue with (vm config, that i provided, uses this values too) So i dont think reverting will help
Could you try to merge locally and test?
I tested vanila with as patch on top. In both cases, the issue persists
OK. Thanks for the report!
As I said before, getting the api key from config before each curl call solves the problem (an example of this solution is in the patch), but I don't think it's a good solution, probably we should check the result (or/and stdout) of curl, reparsing api key if needed, call curl again, before trying to parse it with jq Patch:
I also found that to add several different devices you need to have different id's, so I tested with four devices with different id's. With my patch, all 4 devices were to correctly and syncthing-init.service ran correctly and without errors
I also found out that during my testings in . You are invited to submit that patch, with better formatting.

I am also looking into finding a way to add dummy, but valid devices ID, for testings.
OK I managed to fix the test, regarding checking that the script indeed deletes devices that need to be deleted. I haven't shared it in , because I use there private (sort-of) syncthing's devices' IDs I took from my personal configuration. I'm still looking for a way to generate valid dummy devices IDs. My help request is at syncthing's forum: I also applied a better version of your patch to the (currently draft) . I plan to add many more devices to that test, and maybe do the same for folders. Then I'll also test issue . In the meantime, I'm waiting for a dummy device ID generator.
I managed to create dummy syncthing device IDs and I am using them now in my PR . I saw your PR , and I think we can concentrate our efforts together on my PR at , where I'm currently failing to reproduce your issue, your comments will be appreciated. I am testing your issue without the 2nd commit in my PR (that is identical to your commit at ), and I'm testing that is fixed by reverting commit just for testing (this works :)).