open-traffic-generator / openapiart

OpenAPI artifact generator
MIT License
6 stars 4 forks source link

gosnappi object comparison using DeepEquals fails for same configuration #363

Open ashutshkumr opened 1 year ago

ashutshkumr commented 1 year ago

Version information latest

Describe the bug

Following always results in an error when run against ixia-c.

    api.SetConfig(c)

    if nc := api.GetConfig(); !reflect.DeepEqual(c, nc) {
        t.Fatalf("Got incorrect config: %v\n", nc)
    }

To Reproduce

Run https://github.com/open-traffic-generator/conformance/blob/main/flows/headers/udp/udp_header_test.go with the snippet above inserted in test.

Expected behavior The result should always be that both the configs are equal.

Vibaswan commented 1 year ago

Findings

DeepEqual fails as there is some discrepancy in the config generated in the client side with the config received from the controller, the config generated by gosnappi does not include all the defaults of the non configured field but controller returns all the fields configured with default value

For example:

For the following snippet we can see the difference

tcp := f1.Packet().Add().Tcp()
tcp.SrcPort().SetValue(tc["txTcpPort"].(int32))
tcp.DstPort().SetValue(tc["rxTcpPort"].(int32))

The config created by gosnappi at client end

"packet":  [
      {
        "choice":  "tcp",
        "tcp":  {
          "src_port":  {
            "choice":  "value",
            "value":  5000
          },
          "dst_port":  {
            "choice":  "value",
            "value":  6000
          }
        }
      }
]

The config returned from controller

"packet":  [
        {
          "choice":  "tcp",
          "tcp":  {
            "src_port":  {
              "choice":  "value",
              "value":  5000
            },
            "dst_port":  {
              "choice":  "value",
              "value":  6000
            },
            "seq_num":  {
              "choice":  "value",
              "value":  "0"
            },
            "ack_num":  {
              "choice":  "value",
              "value":  "0"
            },
            "data_offset":  {
              "choice":  "value",
              "value":  0
            },
            "ecn_ns":  {
              "choice":  "value",
              "value":  0
            },
            "ecn_cwr":  {
              "choice":  "value",
              "value":  0
            },
            "ecn_echo":  {
              "choice":  "value",
              "value":  0
            },
            "ctl_urg":  {
              "choice":  "value",
              "value":  0
            },
            "ctl_ack":  {
              "choice":  "value",
              "value":  0
            },
            "ctl_psh":  {
              "choice":  "value",
              "value":  0
            },
            "ctl_rst":  {
              "choice":  "value",
              "value":  0
            },
            "ctl_syn":  {
              "choice":  "value",
              "value":  0
            },
            "ctl_fin":  {
              "choice":  "value",
              "value":  0
            },
            "window":  {
              "choice":  "value",
              "value":  0
            }
          }
        }
]

Technically this should be the expected behavior as gosnappi should not populate all the default values cause that would result in heavy payload ultimately affecting the performance of the API, where as its the Duty of the controller to populate all the default values and validation checks.

Note: the same should be seen in snappi as well

Possible Solution

We can expose some helper methods in the generated SDK which would help us validate whether two configs are equal or not taking into consideration of the defaults.