Skip to content

[redfish] Report a missing firmware inventory member as an error code - #764

Open
nikamirrr wants to merge 1 commit into
sonic-net:masterfrom
nikamirrr:redfish-report-missing-inventory-member
Open

nikamirrr wants to merge 1 commit into
sonic-net:masterfrom
nikamirrr:redfish-report-missing-inventory-member

Conversation

@nikamirrr

@nikamirrr nikamirrr commented Sep 22, 2026 •

Copy link
Copy Markdown

Why I did it

redfish_api_get_firmware_version() returned ERR_CODE_OK for a Redfish response that carries no Version. exec_curl_cmd() only translates cURL-level failures and HTTP 401 into error codes, so a 4xx carrying a Redfish error body reaches the caller as success; the absent Version was reported only as an ERROR log line.

That matters to any caller that discovers which inventory member belongs to a component by probing candidate IDs and keeping the first one that resolves. Such a probe cannot distinguish "this ID exists" from "this ID does not", so it accepts the first candidate unconditionally and never falls through. The observable effects are a component version reported as N/A, firmware update targeting a member that does not exist, and an ERROR logged on every access.

How I did it

Set ret from the Redfish reason when the response carries no Version: ERR_CODE_URI_NOT_FOUND for ResourceNotFound / ResourceMissingAtURI, ERR_CODE_UNEXPECTED_RESPONSE otherwise. Demoted the log to notice, since a probe that is expected to miss must not emit ERROR.

The classification reads the Redfish reason rather than the HTTP status deliberately. A service may answer a GET for a missing inventory member with 400 instead of 404, and 400 is also what it returns for a genuinely malformed request, so the status alone cannot identify the case. Body inspection is already the contract elsewhere in this file - redfish_api_get_eeprom_info() classifies the same way.

The reason is matched on the Reason component of the Base.<ver>.<Reason> code rather than by substring, so an unrelated code that happens to contain one of these names is not misclassified.

redfish_api_get_firmware_list() already maps any non-OK code to version "N/A", so it is unaffected.

How to verify it

test_get_bmc_version_missing_id covers a 400 ResourceMissingAtURI body. test_get_bmc_version_no_version_field covers the other new branch twice: an error the caller cannot act on, and a 200 body that simply omits Version, both reported as ERR_CODE_UNEXPECTED_RESPONSE with version 'N/A'. 120 tests pass across redfish_client_test.py and bmc_base_test.py.

On hardware, a component whose version previously read N/A is reported correctly, and the 'Version not found in Redfish response' ERROR no longer appears in syslog.

Why I did it

redfish_api_get_firmware_version() returned ERR_CODE_OK for a Redfish
response that carries no Version. exec_curl_cmd() only translates
cURL-level failures and HTTP 401 into error codes, so a 4xx carrying a
Redfish error body reaches the caller as success; the absent Version was
reported only as an ERROR log line.

That matters to any caller that discovers which inventory member belongs
to a component by probing candidate IDs and keeping the first one that
resolves. Such a probe cannot distinguish "this ID exists" from "this ID
does not", so it accepts the first candidate unconditionally and never
falls through. The observable effects are a component version reported
as N/A, firmware update targeting a member that does not exist, and an
ERROR logged on every access.

How I did it

Set ret from the Redfish reason when the response carries no Version:
ERR_CODE_URI_NOT_FOUND for ResourceNotFound / ResourceMissingAtURI,
ERR_CODE_UNEXPECTED_RESPONSE otherwise. Demoted the log to notice, since
a probe that is expected to miss must not emit ERROR.

The classification reads the Redfish reason rather than the HTTP status
deliberately. A service may answer a GET for a missing inventory member
with 400 instead of 404, and 400 is also what it returns for a genuinely
malformed request, so the status alone cannot identify the case. Body
inspection is already the contract elsewhere in this file -
redfish_api_get_eeprom_info() classifies the same way.

The reason is matched on the Reason component of the Base.<ver>.<Reason>
code rather than by substring, so an unrelated code that happens to
contain one of these names is not misclassified.

redfish_api_get_firmware_list() already maps any non-OK code to version
"N/A", so it is unaffected.

How to verify it

test_get_bmc_version_missing_id covers a 400 ResourceMissingAtURI body.
test_get_bmc_version_no_version_field covers the other new branch twice:
an error the caller cannot act on, and a 200 body that simply omits
Version, both reported as ERR_CODE_UNEXPECTED_RESPONSE with version
'N/A'. 120 tests pass across redfish_client_test.py and bmc_base_test.py.

On hardware, a component whose version previously read N/A is reported
correctly, and the 'Version not found in Redfish response' ERROR no
longer appears in syslog.

Signed-off-by: Nikolay Mirin <nmirin@nvidia.com>
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 1 pipeline(s).

@nikamirrr
nikamirrr marked this pull request as ready for review September 23, 2026 00:17
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants