fix: merge or refuse an entity's conflicting definitions rather than dropping one

[sini]

#678 (comment)

Summary

Merge:

• Merges an entity's list-valued keys instead of overwriting them, as den.hosts' freeform type merged with lib.recursiveUpdate, which treats a list as an opaque leaf, so two files each writing den.hosts.<system>.<name>.includes kept one list and dropped the other with no conflict warning.
• Concatenates rather than picking a winner, because that is the module system's own rule for a list-valued option (listOf merges by concatLists) and den's rule at the aspect tier (aspectContentType's deepMerge), so the entity registry now agrees with both instead of adding a third behaviour.
• Applies to every list-valued key an entity carries, since includes, excludes and classes accumulate everywhere else they appear.
• Concatenates in declaration order, as defs reach this merge in reverse declaration order, which is measured rather than assumed and is the same ordering that makes the scalar arm read as first-declaration-wins.

Conflicts:

• Refuses two definitions of a key that is neither a mergeable attribute set nor a list, as they previously took the first and dropped the other, and a type mismatch such as a list against a string resolved the same silent way.
• Refuses when either side is a plain scalar and the values differ, which covers both arms. Requiring both sides to be scalars leaves the mismatch silent, which is what an earlier form of the predicate did.
• Excludes functions deliberately, since == on two functions is always false and comparing them would reject two identical definitions of a class module or of instantiate.
• Names a value in the message only where rendering it is safe, because builtins.toJSON throws on a derivation or a function and either can be one side of a conflict.

Why it went unnoticed:

• An attrset key under the same two definitions merged normally, so the collection read as having no effect rather than as a failed merge. A users.alice and users.bob pair across two files both survive, which is what localised the defect to list leaves rather than to the collection keys or the registry's recursion.
• Instance-level collections were read by nothing until recently, so there was no way to observe which list survived.
• Both arms are PRE-EXISTING rather than regressions, measured against a tree predating the instance collections being read at all, where the scalar conflict and the type mismatch resolve identically. Making the collections meaningful changed observability, not behaviour, so a list key on an entity has been losing definitions since the gen-schema entity port.

gen hub

Bumps templates/ci/flake.lock's gen pin from 0b6fbd8d to 0004f3c9 over the two chore: commits, which moves gen-schema f8e0e171 to 48cfb992 and leaves gen-merge held at 08fcdd1 on the flake path, so nothing above is affected.

• Fixes a separate report, a den.schema.user option declared without default = { } failing with gen-merge: the option ... is used but not defined. The first of the two bumps deliberately did NOT fix it, and said so, because the cause was never the hub rev.
• The cause is entry-path divergence. nix/lib/schema.nix dispatches on inputs ? gen: only templates/ci declares that input, so den's own suite takes the FLAKE path while every other consumer takes the builtins.fetchTarball fallback. The fallback enters the hub standalone, where no follows exist and each member resolves its deps from its own lock, so one hub rev yielded two different closures — gen-merge 08fcdd1 (guarded) on the flake path and f7e3afb3 (pre-guard) standalone.
• gen-schema 48cfb992 carries 2a33f81 in both of its own locks, which is what makes the two paths agree rather than the hub pin moving.
• Also drops the provider test fixture's gen-schema input, which was referenced nowhere and pinned 4bd0f6eb, a rev predating gen-merge entirely. It put a second gen-schema node in the CI lock, so one lock carried two revisions of one library — the incoherence the hub indirection exists to prevent, in the tree that documents it.

Behaviour changes

• A list-valued key on an entity now accumulates across definitions where one definition previously overwrote the other. A configuration that wrote the same key in two files and relied on one winning will start seeing both.

• Two definitions of a non-mergeable key now refuse instead of silently resolving to the first. A configuration that wrote a key twice with different values, or with mismatched types, will start failing where it previously picked one. Definitions that agree are unaffected.

• A consumer that declares no gen input now resolves gen-merge 2a33f81 where it previously resolved f7e3afb3. That is the fix for the report above, and it is the only closure change on the fallback path.

Validation

• nix develop -c just ci: 1221/1221, exit 0, zero failures and zero errors, read off stderr with the collected count agreeing with the numerator.

• Falsified the three defect cells against the unfixed merge with the tests held in place, so the red arm measures the fix rather than the cells' absence. Both control cells stay green in that arm, which is what makes them controls rather than padding.

• Pinned declaration order in its own cell, as concatenating in either direction makes both entries present and so passes the other cells.

• Reproduced the report before changing anything, and measured the surviving entry rather than inferring it: the first definition won, not the last.

• Measured both arms against a pre-existing tree rather than reasoning about blame, which is what established these as latent defects rather than regressions.

• Verified the hub bump against the reporting user's real configuration rather than a reduction, with a live control: home-manager.users.<u>.programs.helix.ignores yields its list at exit 0 on this branch, and the same attribute at the previous pin, same instrument, exits 1 with gen-merge: the option ... is used but not defined.

• nix flake check on minimal, default and noflake, none of which declares a gen input, so all three exercise the fetched fallback that consumers take rather than the flake path the suite measures.

[theutz]

Nice! Can confirm this fixes the problem on my local.

[theutz]

This is a good catch!