SET_ALWAYS re-resolve applies stale stored plugin objects — placeholder and cross-device names overwrite correct devNames (v26.6.3, follow-up to #1650)

[oseagull]

What installation are you running?

Production (netalertx) 📦, v26.6.3, Docker (host network), ~300 devices on a multi-VLAN office network (ARPSCAN + SNMPDSC + NBTSCAN + DIGSCAN).

Is there an existing issue for this?

• I have searched the existing open and closed issues. Closest is devName in SET_ALWAYS is not updated if already set #1650, whose fix (the SET_ALWAYS re-resolve pass released in v26.6.3) is what this report is about.

Current Behavior

On the first scan cycle after upgrading to v26.6.3 with NBTSCAN_SET_ALWAYS=['devFQDN','devName'] (set long before the upgrade) and NBTSCAN_RUN='before_name_updates', the new re-resolve pass logged:

[Update Device Name] SET_ALWAYS re-resolve - Found (DIG/AVAHI/NSL/NBT): 99 (0/0/0/99), Not Found: 90
[Update Device Name] SET_ALWAYS re-resolve - DB rows updated: 99

Of those 99 devName updates, roughly a quarter were wrong:

1. A literal <unknown> placeholder became a devName. A printer (no NetBIOS) had <unknown> stored as its NBTSCAN result; the re-resolve pass wrote that placeholder over a correct, manually-set name.
2. A 4-days-stale pre-rename hostname was re-applied. A workstation had been renamed (live nmblookup -A confirmed the new NetBIOS name at that moment), but the stored NBTSCAN object still held the first-captured old name — the pass overwrote the correct current name with the stale one.
3. One device received a different device's hostname. A PC's devName was overwritten with the hostname of another machine — consistent with an IP-keyed lookup (Object_SecondaryID) hitting a row left behind after DHCP churn moved the IP between devices.

Expected Behavior

The re-resolve pass should only apply plugin results that are fresh and valid — never failure placeholders, never first-capture snapshots older than the device's current state, and never values matched by IP when the IP has changed hands.

Why it happens (from reading the code)

update_devices_names() Step 1b re-resolves already-named devices, but the resolver strategies (resolve_dig / resolve_nbtlookup / …) read stored Plugins_Objects rows (matched by Object_PrimaryID / Object_SecondaryID), not live lookups. There is no freshness or validity filter, so whatever the plugin store holds — failure placeholders, stale first captures, rows inherited via reused IPs — gets re-applied as authoritative every cycle.

Suggested fixes (any subset would help)

• Skip placeholder/sentinel values ((unknown), (name not found), <unknown>, empty) as re-resolve results.
• Only apply a stored plugin object if it is newer than the device's last devName change (or a configurable freshness window).
• In the re-resolve pass, only trust Object_PrimaryID (MAC) matches; never apply Object_SecondaryID (IP) matches.
• Alternatively: make the re-resolve pass live-probe instead of store-read.

Workaround we applied

Removed devName from NBTSCAN_SET_ALWAYS (the pass skips when no name-resolution plugin lists devName), restored the corrupted names from a pre-upgrade backup, and locked curated names (Source=LOCKED). Happy to test a dev image.

Steps To Reproduce

1. v26.3 or earlier with NBTSCAN_SET_ALWAYS=['devFQDN','devName'], devices named over weeks (so the plugin store contains stale/placeholder rows).
2. Rename one Windows machine on the network; let DHCP move an IP between two devices; have one device that answers no NetBIOS (printer) with <unknown> stored.
3. Upgrade to v26.6.3, wait one scan cycle.
4. Observe SET_ALWAYS re-resolve - DB rows updated: N and compare devNames against live nmblookup -A — stale/placeholder/cross-device names appear.