Shim, if I'm understanding correctly, what is happening is rather then reporting an empty JSON array, the report currently contains an array with an empty string. This fails validation on HBI.

E.g. the plugin currently produces
ip_addresses: ['']

but we need
ip_addresses: []

Can you confirm if the change to be made will be on the plugin side and change component of this BZ appropriately if so?

@sanket, is there a way you download and attach the generated tar?

@Kevin, I have tried to simulate the same process as it is defined in our generator here: https://github.com/theforeman/foreman_rh_cloud/blob/foreman_1_20/lib/foreman_inventory_upload/generators/slice.rb#L48

irb(main):014:0> File.open(File.join('/tmp/', "try.json"), 'w') do |slice_out|
irb(main):015:1* ss = ForemanInventoryUpload::Generators::JsonStream.new(slice_out)
irb(main):016:1> ss.object do
irb(main):017:2* ss.array_field('ip_addresses', :last) do
irb(main):018:3* ss.raw([].join(' ,'))
irb(main):019:3> end
irb(main):020:2> end
irb(main):021:1> end
=> #<File:/tmp/try.json (closed)>
irb(main):022:0> `cat /tmp/try.json`
=> "{\"ip_addresses\": []}"

I don't see an empty string in the output. The only way an empty string could get in is if the field contains an empty string, but I wasn't able to create such a record in Satellite:

irb(main):032:0> nn = hh.interfaces.first
=> #<Nic::Managed id: 1, mac: "52:54:00:c8:d2:5f", ip: "192.168.121.54", type: "Nic::Managed", name: "rhel7-6-6.dell-r730-055.example.com", host_id: 1, subnet_id: nil, domain_id: nil, attrs: {}, created_at: "2020-03-10 15:23:04", updated_at: "2020-03-10 15:23:36", provider: nil, username: nil, password: nil, virtual: false, link: true, identifier: "eth0", tag: "", attached_to: "", managed: true, mode: "balance-rr", attached_devices: "", bond_options: "", primary: true, provision: true, compute_attributes: {}, execution: true, ip6: nil, subnet6_id: nil>
irb(main):033:0> nn.mac
=> "52:54:00:c8:d2:5f"
irb(main):034:0> nn.mac = ''
=> ""
irb(main):035:0> nn.valid?
=> true
irb(main):037:0> nn.mac
=> nil
irb(main):038:0> nn.ip
=> "192.168.121.54"
irb(main):039:0> nn.ip = ''
=> ""
irb(main):040:0> nn.valid?
=> true
irb(main):041:0> nn.ip
=> nil
irb(main):042:0>

Thanks @Sanket!

@Kevin, looked into the result Sanket sent. Satellite sends empty array:

For first host:
    "ip_addresses": ["1.2.3.4"], (obfuscated by me)
For second host:
    "ip_addresses": ["5.6.7.8"], (obfuscated by me)
Host 3 (virt-who...):
    "ip_addresses": [],
Host 4 (virt-who...):
    "ip_addresses": [],

Sanket, per comment 4, and the report from comment 3, my understanding must have been incorrect. Can you still reproduce this? If so, then it's probably an issue with HBI.

Note, I received confirmation (outside this BZ) that Sanket can still reproduce.

Shaun, after some investigation, we're thinking this might actually be an issue with HBI's validation. Can we get an HBI developer to take a look/work with us on this one?

Inventory devs took a look at this and determined...

a) ...these payloads are failing HBI validation
b) ...the validation failure is caused by empty arrays in the "ip_addresses" and "mac_addresses" JSON fields; e.g., 
  `"ip_addresses": [],
   "mac_addresses": [],`

We have a couple of options to move forward:

1) Omit the "ip_addresses" and "mac_addresses" fields if there are no IP/MAC addrs to report (i.e., don't send empty array). This is change on the reporter side and since Satellite is on-prem I'm not sure how feasible this is (we'd need an opinion from an SME).
2) Change HBI to allow a value of empty array for these JSON fields, which would most likely indicate an "overwrite operation". 
2a) This change might have some unwanted side effects since multiple reporters can send in data for a single host and it is HBI's job to assimilate the data into a single record of truth; e.g., reporter1 might send in valid ip_addresses then an update like this from Satellite would cause those ip_addresses to be cleared out. This needs some more thought.

Let me know on the feasibility of 1) and which would indicate whether or not we should start exploring 2) above.

Since we have verified fix on plugin versions 1.0.9 and 2.0.9 (see Comment 14 ), I'm moving bz to VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.8 release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4366