Discovery logs for the Object ID check before Identifier entries logs "Identifier: , Rule 1 Searched on <> for attributes: :" as it it were an identifier entry - Known Error

Discovery logs for the Object ID check before Identifier entries logs "Identifier: , Rule 1 Searched on <> for attributes: :" as it it were an identifier entry Description When running Horizontal Discovery, and checking the logs in the discovery status, since Paris the following confusing Identifier log is added:

Identifier: , Rule 1: Searched on for attributes: : Skipped Identifier Entry Source Identifier: Empty or

Identifier: , Rule 1 Searched on <> for attributes: :Skipped Identifier Entry. or

Identifier: , Rule 1 Searched on <> for attributes: :Match This does not break anything, but does cause confusion, as the assumption is that something must be broken in the Identification rules for such a message to appear when debugging identification issues.

This is not an Identifier entry/rule of a CI identifier, is done automatically, and corresponds to the search on sys_object_source for source_native_key, which except for some cloud discovery and imports is usually not present or needed in the IRE payload.

"identificationAttempts": [ { "attributes": [], "info": "sys_object_source NO_MATCH", "identifierName": "", "attemptResult": "NO_MATCH", "hybridEntryCiAttributes": [] },... Steps to Reproduce

1- Perform a quick discovery on an IP e.g. Linux server.

2- Check the Discovery Log in the Discovery Status: Unexpected Rule 1 is showing in the Discovery logs in the Discovery Status, and the first actual Identifier rule appears as Rule 2. Rule 1: Searched on for attributes: : Skipped Identifier Entry Source Identifier: Empty Rule 2: Searched on for attributes: serial_number, serial_number_type: Match

The log does not show what was really occurring (i.e. would be expected "Identifier: Object ID Rule: Searched on sys_object_source for source_native_key"), and numbering does not map to the actual active Identifier entries.

Workaround This problem has no workaround, and is targeted to be fixed in a future release. To receive notifications when more information becomes available, subscribe to this Known Error article by clicking the Subscribe button at the top right of this form.