fix(collector): honor a device type set in the config file - #1067

Sure, doing the 1.
2- yes, took some help from Codex.

Both done, in two commits.

6d34caa is the lookup change on its own, as you suggested: the overrides are parsed once into a map keyed on the lowercased device name, HasDeviceTypeOverride is a method on the config reading that map instead of a package function, and GetDeviceOverrides still returns the slice so ordering is unchanged. Matching stays case-insensitive and a device listed twice still resolves to its first entry. The mock is regenerated for the new interface method.

c405ebd cuts the tests down — 108 lines removed against 26 added across detect_test.go and metrics_test.go. What's left is the cases that actually distinguish an unset device type from an explicitly configured one.

go vet ./collector/... and gofmt are clean; collector/pkg/config and collector/pkg/collector pass. collector/pkg/detect has four failures on this Windows host, but they reproduce identically on master — they assert /dev/sda against a path the OS renders differently.

@justadityaraj - I rebased this on some changes I merged. decided to keep things as case-insensitive, for now, since its not consistent elsewhere. can you please do a quick sanity check?

Checked it, rebase looks right. Both of your edits hold up, and one of them was load-bearing in a way I had not accounted for.

The fix still works end to end. Driving the real config package and the real Detect with a capturing shell, using the issue's exact config (devices: [{device: /dev/sda, type: scsi}]) and its scan result (/dev/sda, scanned type sat):

master 5bf0b25:  smartctl --info --json /dev/sda
6dbe074:         smartctl --info --json --device scsi /dev/sda

The first line is byte-for-byte the log in #1063. The configured scsi correctly beats the scanned sat.

The operand reorder was not cosmetic, it was needed. HasDeviceTypeOverride is a pure read, so (type != "scsi" && type != "ata") || Has(x) is result-identical to what I had. But your ordering also keeps the config off the path for every non-scsi/ata device, which is why .AnyTimes() is now required rather than papering over anything: in the megaraid,14 case the call genuinely never happens. I checked the tests are still load-bearing by reverting only the guard at both call sites to master's form:

--- FAIL: TestDetect_SmartCtlInfo_ConfiguredDeviceType/should_keep_a_configured_scsi_type
--- FAIL: TestMetricsCollector_Collect_ConfiguredDeviceType/should_keep_a_configured_scsi_type
        Want: [--xall --json --device scsi sda]
        Got:  [--xall --json sda]

The other two cases pass under that mutation, which is correct: they exist to pin the behaviour that must not change.

EqualFold over the map reads fine to me, and it is the more consistent choice next to #1073. I confirmed the extraction into getDeviceOverride is behaviour-preserving rather than assuming it: GetCommandMetricsInfoArgs and GetCommandMetricsSmartArgs return byte-identical results to master across duplicate device: entries and mixed-case paths, including that first-match-wins is unchanged.

#803 composes cleanly, and makes the metrics.go half necessary. Now that SmartCtlInfo no longer overwrites device.DeviceType with smartctl's resolved transport, a pinned scsi survives detection and arrives at Collect() still as scsi, so it needs the same guard there. Before #803 it would often have been rewritten to sat and passed through on the non-standard branch by accident.

go test ./collector/... at the head fails the same five pre-existing path tests as master on my Windows host, no more and no fewer. go vet and gofmt -l clean, all 15 checks green.

One thing worth a release note, not a code change: anyone who already has type: scsi or type: ata in their collector.yaml will start getting a --device flag they have never been sent. That is the point of the fix, but the suppression you are relaxing was added precisely because -d scsi can lose metadata on ata drives that docker detects as scsi, so it seems worth a line rather than a silent change. None of the type: examples in example.collector.yaml are scsi/ata, so the blast radius is only configs that pin one deliberately.

I also fixed the PR description: it still claimed there was no config.Interface change and no mock regeneration, which stopped being true in 6d34caa, and the short-circuit paragraph described my ordering rather than yours.

Same disclosure as before, per AI_POLICY.md: this check was done with Claude Code. The before/after commands above are real runs against the two trees, not reasoning about the code. I still do not have the reporter's USB Seagate drive, so smartctl's exit status on that specific hardware remains the one thing I cannot confirm.