Handle members: null response

[shevchenko-evgeny]

Some BMCs (for example, BF-24.10-17 on BlueField-3 cards) return null instead of an empty array for members fields. This causes NICO pre-ingestion to fail with a deserialization error, for example:
level=INFO span_id=0xfef03873c4xxxxxx msg="Failed to explore 10.xx.xx.xx:443: Error while performing Redfish request: context: boot options; json error: invalid type: null, expected a sequence: None (response code: None)" error="Error while performing Redfish request: context: boot options; json error: invalid type: null, expected a sequence: None (response code: None)" location="crates/site-explorer/src/lib.rs:1849"
This PR handles that case by deserializing null values into empty arrays for required non-nullable collections.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[poroh]

We should not change behavior of all arrays because of quirk of one firmware of one vendor. To handle tnull in BootOption collection you can use quirks approach:

nv-redfish/redfish/src/bmc_quirks.rs

Line 42 in 75f4e97

impl BmcQuirks {

To support this behavior you can add additional function like fn boot_option_null_members() and if it is detected then use something similar to

nv-redfish/redfish/src/patch_support/collection.rs

Line 55 in 75f4e97

async fn expand_collection(

This is not exact fit because expand_collection purpose is to handle quirks inside member's structure, not collection itself but approach should be similar: instead of retrieving BootOptionsCollection schema struct code in https://github.com/NVIDIA/nv-redfish/blob/main/redfish/src/computer_system/boot_option.rs#L46 should extract JSON Value first, apply patch on Members (convert null -> empty array) and then translate to original BootOptionCollection

[poroh]

I understand that this can be bit overwhelming, so if you want I can implement this by myself and you can check my branch against your BF4 that cannot properly return boot options collection.

[shevchenko-evgeny]

@poroh Thanks for the feedback! I agree that this case is probably better handled by introducing a quirk rather than changing deserialization globally. That was actually my first thought as well.
The reason I initially chose the deserialization approach is that these kinds of issues are relatively straightforward to handle at that stage, and I suspect that returning null instead of an empty array may not be uncommon across different BMC implementations.
That said, I’ll try implementing this in the quirk layer first. If I get stuck, I’ll ping you for help.

[yoks]

It looks like a error in implementation of Redfish spec for this Firmware, Collection is always variable length array, so it could not have null in it (only fixed length array can).

Maybe we should file a bug against this particular Redfish version in BF3 as well.