Change:
nodes.machine = { services.syncthing = { enable = true; <del> devices.${testName} = { </del> <ins> settings.devices.testDevice = { </ins> id = testId; }; <del> folders.testFolder = { </del> <ins> settings.folders.testFolder = { </ins> path = "/tmp/test"; <del> devices = [ testName ]; </del> <ins> devices = [ "testDevice" ]; </ins> }; <del> extraOptions.gui.user = "guiUser"; </del> <ins> settings.gui.user = "guiUser"; </ins> }; };

Discussion:
Since , I'm getting long timeouts on my deployments with: in No warning, no deprecation, nothing, this is bad. My SyncThing configuration: Steps to reproduce the behavior: to this PR breakage Clear instructions on why this is happening or fixes or warnings. for the maintainers for the people actively taking part in those recent changes
Can you check if the following also fails for you? I just updated my system using and I did experience the issue after the first , which also updated and triggered a restart of . However I tried to play a bit with the dash script that runs, and then I reverted it back and didn't fail (I ran again) - it seems to be because was already running. Did you try to simply restart ? Or test if the issue persists after reboots?
Your command fails for me too. I didn't restart anything yet, I didn't reboot, this issue needs to be solved without any manual intervention, otherwise this is badly broken. It has to upgrade gracefully or it has to provide proper migration instructions in the release notes (which are not there, neither in the Discourse post for unstable breaking changes).
this was not meant to be a strongly breaking change. Putting a message in would have been nice, but I haven't thought about it when I merged the PR. We hoped the module options renaming would be enough. Please forgive us for the inconvenience. Now regarding your issue: tries to do it's best when switching generations, but sometimes big rebuilds cannot be switched fully smoothly. Please try to reboot, or at least restart . My intuition tells me that didn't run when 's API was ready - although the systemd service itself was running at that point. If my guess is correct, your issue might not be strictly due to , but it somehow appeared only now - possibly due to other changes done between your previous NixOS generations - or simply due to the nature of the particular generation switch you made now.
weird, seems like raito has no declarative stuff configured so there should be no syncthing-init service anyway, since we only configure it if settings are set. but maybe that fails due to some default values making the set not-empty. I will take a look tomorrow to fix this to work as expected.

Yeah the problem is always, that people only report their errors if after we merge them because no one chims into open PRs to check if it breaks their workflow :) But yeah, sorry for the breakage. but I'm certain we will fix those minor issues in time.
Please provide enough notice for everyone, this issue is quite hairy. Unfortunately, those are all wrong assumptions I think, I do not have a system syncthing service, so this is meaningless. I need to start the user service and then the syncthing-init will still fail, relying on a system service. This is a massive breakage for people having in their configuration… No matter what I do I cannot get syncthing-init to start.
I think here, proper testing coverage would have uncovered the system service issue ;) and the missing declarative options. :) But I am not maintainer of that subsystem, more a user.
I guess the quickfix would be to set syncthing-init not if systemService = false is set. I will prepare a PR for that
I'm a bit confused - what's the point of setting , , and (in fact, what's the point of using the NixOS module at all) if you're not using the systemd service nor the declarative configuration? Just to get syncthing in PATH and open the firewall? EDIT: and the upstream systemd units, i guess
I also wonder: how come configuration hasn't failed before? did you rely upon in any way? Is this merely an issue of a systemd service you don't need that now is enabled and fails?
So my take on this is, since there was neither folders, devices or anything else set, the old check just skipped creating the service, so raito never had the syncthing-init service until we merged this PR, which played with the mkIf logic and now it's enabled by default and breaking things.
If indeed this is the case, we need to find out why in Raito's case.
well the default value for settings (checked in the repl): so that was changed, also the check got broken with
I probably never relied on that.
I always had a non-declarative SyncThing configuration from the start.
I thought it was creating a user systemd service, but you are right by reading the code, it is not the case.

I think it must be some mixup with Home-Manager.
I still don't understand why fails when . What if someone wishes to set but still set some - I don't think we should change the logic in I do think this logic should documented though, such that users like will be able to disable if it causes them issues they don't want to debug.
How did you check that ? Do you think it is even possible to truely set ? I'd like to play with that too. I have proposed an alternative fix to this issue at - touching only the documentation for the option instructing how to completely disable .
ah I just put raitos config in a file and ran . To get settings to be {} on default we would need to remove all the default values in the nested types, since the nested default values override the outer ones.
Branch-off is tomorrow night, we really need a fix here :) — were you able to find a convenient solution? (I still suffer from like 10 minutes long restart of home-manager due to this…)
To be more specific, and explain this for others, I created the following : I deleted all lines in the definitions: And while , I ran: And in the REPL I typed: Which adds the functions to the repl's scope. Then I typed: This seems problematic to me. Do you think this can be solved? EDIT: Yes, with :
we'd appreciate your review on or on ? did you try to simply set ? In my PR () I suggest to simply document this.
I vote we revert for now as it's not clear how to resolve this without breaking anyone's setup and that PR's changes seem unnecessary anyway (simply adding s to existing options should be fine). Arguably my "fix" in was also not well thought out. Assuming you mean , that will just get merged with the other settings and be a no-op.
sadly thats not the case, with the settings we mirror how the API expects values and not everything we can set is under folders, devices or options. before that people could set folders twice (once through folders and once through extraSettings) which could lead to weird behaviour
Ran into this, the service times-out after 1min. I also use , my goal is to get NixOS to open the firewall, but manage the service via HM.

My config is: Could we make also disable ?
I feel like you should probably not enable the service if you only want to open ports. At least I definitely don't think that's the intended use case for .
Agreed it's not ideal, but the HM module has no easy way to configure the ports and I'd rather do this than hardcode the default ports myself. What do you think of changing to instead of ?
Sounds good to me. is the place to add this.. Then what is the intended usecase for ? Perhaps the documentation for it could be improved a bit..
should reference a target, not a service. If anything we should then have a that pulls in everything which in turn has As for systemService, I'll expand on that later.