Change:
preStart = optionalString (settings != null) '' if    [ -e "$STATE_DIRECTORY/AdGuardHome.yaml" ]  && [ "${toString cfg.mutableSettings}" = "1" ]; then <ins> # First run a schema_version update on the existing configuration # This ensures that both the new config and the existing one have the same schema_version # Note: --check-config has the side effect of modifying the file at rest! ${lib.getExe cfg.package} -c "$STATE_DIRECTORY/AdGuardHome.yaml" --check-config </ins> # Writing directly to AdGuardHome.yaml results in empty file <del> ${pkgs.yaml-merge}/bin/yaml-merge "$STATE_DIRECTORY/AdGuardHome.yaml" "${configFile}" > "$STATE_DIRECTORY/AdGuardHome.yaml.tmp" </del> <ins> ${lib.getExe pkgs.yaml-merge} "$STATE_DIRECTORY/AdGuardHome.yaml" "${configFile}" > "$STATE_DIRECTORY/AdGuardHome.yaml.tmp" </ins> mv "$STATE_DIRECTORY/AdGuardHome.yaml.tmp" "$STATE_DIRECTORY/AdGuardHome.yaml" else cp --force "${configFile}" "$STATE_DIRECTORY/AdGuardHome.yaml"

Discussion:
I recently updated my system and then AdGuardHome ceased to work. The error message in the flake is: Originally I thought it was because /nix/store/* is a JSON file, but it appears it is always that way. I'm not entirely sure what is missing to produce that error. I had a set up for rewriting, but commenting that out continued to produce the error so it doesn't seem to be that. up AdGuardHome using the above stanza. up the service. It would start up and protecting my location from the evils of surveillance capitalism. N/A N/A host os: multi-user?: sandbox: version: nixpkgs:
Please set a to an older value, or update your configuration to match the upstream . This behavior is caused by . It essentially fails to consume your config, as it assumes that the YAML produced follows the latest schema, as . The error likely comes from a missing (under ).
Assuming this could happen periodically, is there a mechanism we can use to warn others about it on build? I would have never guessed it was a schema change plus now I need to manually edit a file that I've only created/maintained with a nix declaration.
You do not need to manually edit the file. You can simply set to the value that was used before. In your case, would likely work, as it was the . From thereon, you won't have to touch that option again, except if you want to utilize configuration options that are introduced in a later schema upstream. I don't see a way to compromise on the default value here, as we'd either never allow newer options by default (e.g., by defaulting to a schema version of ), or we sometimes get this breakage.
I'm not suggesting we change the default value handling, but what about a warning/notice if it isn't set that says there may be periodic breakage when the package is updated? Likewise, we could give a warning/notice when the current schema version doesn't match the one if it is set? I've noticed that other packages like and both have warnings when variables/settings change.

In both cases, it would help with discovery the process or at least the first steps, which would give a better experience since it is difficult to keep up with every package and it's changes and it is a non-obvious (to me at least) solution.
So the idea would be to issue e.g. a warning if ? I could see that this would work, yes. I think handles this similarly, but nextcloud could have problems with a missing step in the upgrade path. For adguard home, one could work just fine for all eternity, as the schema gets updated either way on start. That's why the adguardhome test gets away with .
Since there is a problem with it being out of sync, it has some similarities to nextcloud's update. Related to the fix, I changed my setting to this: but it produced this file: This doesn't work. I noticed that is still 24, which seems not to fit with the suggested fix. I did try setting mutableSettings. This is in the build output: But it still failed. I also tried filtering... which produced this file: which also failed to run. (at least I know why I see yaml sometimes and json the other times. :)
Regarding YAML vs JSON: JSON is a strict subset of YAML, so all JSON is valid YAML. That's why is often used to generate the configs for YAML-consuming tools. The changing is a side-effect of , which apparently performs the schema migration while checking (this feels wrong, now that I think about it). This might also explain why you're seeing JSON for but YAML for everything else. It's likely that the JSON gets rewritten as YAML by the checkPhase. Regarding your problem: You could try to set to an even older version. I was just assuming that should work here, as it was the version before the current one (so I'm a bit surprised that this does not change anything). Also note that belongs to the same level as , not inside it (so it does not end up in the YAML).
I mentioned it in the PR but it got sadly merged. I'll try to get to it this week and create a fix.
This wasn't detected by the tests because they pin the to 0, correct?

Maybe we can add another test case for a default :thinking:
After a bunch of things, I edited , deleted everything but the first few lines, and then did a redeploy. That got rid of a bunch of entries that were in probably when I was manually editing(?) but weren't updated (maybe because the schema was set to 24 before it was copied up in the Nix closure?). Edit: That ended up working, but not sure if there isn't something that can be done to help then next person who encounters this.
I could never get AGH to properly configure thought the Nixos settings, so I've just been using the web interface for configuration. However with every update it breaks configuration again.
Can you open a new issue and share the relevant config there? Because that should not happen, at least if you set .
IMHO this should not be closed. I just tested the schema_version pinning: setup a VM using git rev. this to my config: worked fine. I updated unstable to rev. restarted and it failed to start AGH: then stopped AGH deleted the file restart AGH: That was just me not really knowing the syntax. This works:
That's close to my problem. Deleting the effectively fixed it for me. I suspect the reason is that the schena is rolled forward to 24 before the closure is installed (the one in /nix/store) but when it is mwrged with the one in /var/lib, it merged the 24 into that file so the service doesn't roll the old data (what was in /var/lib before update) up to the new schema and blows up.
Oh, I think that I understand the problem now. you're likely correct. To reiterate the problem, and let's assume without loss of generality that the old schema version is and the new one : Config file in is on version AGH gets updated in nixpkgs to schema version nix-controlled portion of the config file gets recreated by the module running the AGH with bumps the schema version and layout in the nix-controlled portion The generated and the residing configs get merged, where the generated one takes precedence So the old config is on a schema version pre 24, while the one that gets merged is at 24.

I'd assume one fix would be to bump the residing schema version prior to merging, and another one would be to not merge if residing version < generated version. I'm preferring the first approach, as the second one does the same, but requires one additional restart. Thanks to the statefulness of it, it is likely sufficient to just add into the prior to merging, which should bump the residing config to the "new" schema version. Any objections?
I think that's whats happening. This results in AGH unable to start.
Upgrading both sides (nix-controlled and previous) before merging sounds like it would a good solution, I'm in favor of your first suggestion.
Has anyone figured out how to add custom filters to the nixos configuration? When adding a custom filter through the WUI it will look in the AGH config like this: ` However I don't know how to recreate that in the nixos configuration file. It did not like this:
It is likely not related to this issue. You can supply as list of strings, e.g.