sairedis.rec items are not in proper order

[mgheorghe]

i load a DASH config via gnmi_client.py from the NPU on the DPU i see the config is proper

i take the sairedis.rec file from the DPU and do the steps from https://github.com/sonic-net/SONiC/wiki/How-to-Use-SAI-Player to load the config back in same exact DPU after a fresh power on

at this time we observe the dash config is not properly loaded into DPU ASIC investigating further we observed that SAI_OBJECT_TYPE_OUTBOUND_CA_TO_PA_ENTRY was recorded before SAI_OBJECT_TYPE_VIP_ENTRY

2024-06-11.15:44:30.899954|C|SAI_OBJECT_TYPE_VNET||oid:0x7900000000001d|SAI_VNET_ATTR_VNI=1
2024-06-11.15:44:30.935415|C|SAI_OBJECT_TYPE_OUTBOUND_CA_TO_PA_ENTRY||{"dip":"1.4.0.1","dst_vnet_id":"oid:0x7900000000001d","switch_id":"oid:0x21000000000000"}|SAI_OUTBOUND_CA_TO_PA_ENTRY_ATTR_UNDERLAY_DIP=221.2.0.0|SAI_OUTBOUND_CA_TO_PA_ENTRY_ATTR_OVERLAY_DMAC=00:1B:6E:00:00:01|SAI_OUTBOUND_CA_TO_PA_ENTRY_ATTR_USE_DST_VNET_VNI=true||{"dip":"1.1.0.1","dst_vnet_id":"oid:0x7900000000001d","switch_id":"oid:0x21000000000000"}|SAI_OUTBOUND_CA_TO_PA_ENTRY_ATTR_UNDERLAY_DIP=221.0.0.1|SAI_OUTBOUND_CA_TO_PA_ENTRY_ATTR_OVERLAY_DMAC=00:1A:C5:00:00:01|SAI_OUTBOUND_CA_TO_PA_ENTRY_ATTR_USE_DST_VNET_VNI=true
2024-06-11.15:44:31.032899|C|SAI_OBJECT_TYPE_PA_VALIDATION_ENTRY||{"sip":"221.2.0.0","switch_id":"oid:0x21000000000000","vnet_id":"oid:0x7900000000001d"}|SAI_PA_VALIDATION_ENTRY_ATTR_ACTION=SAI_PA_VALIDATION_ENTRY_ACTION_PERMIT||{"sip":"221.0.0.1","switch_id":"oid:0x21000000000000","vnet_id":"oid:0x7900000000001d"}|SAI_PA_VALIDATION_ENTRY_ATTR_ACTION=SAI_PA_VALIDATION_ENTRY_ACTION_PERMIT
2024-06-11.15:44:31.034743|c|SAI_OBJECT_TYPE_VIP_ENTRY:{"switch_id":"oid:0x21000000000000","vip":"221.0.0.1"}|SAI_VIP_ENTRY_ATTR_ACTION=SAI_VIP_ENTRY_ACTION_ACCEPT
2024-06-11.15:44:31.473714|c|SAI_OBJECT_TYPE_DIRECTION_LOOKUP_ENTRY:{"switch_id":"oid:0x21000000000000","vni":"1"}|SAI_DIRECTION_LOOKUP_ENTRY_ATTR_ACTION=SAI_DIRECTION_LOOKUP_ENTRY_ACTION_SET_OUTBOUND_DIRECTION
2024-06-11.15:44:31.829974|c|SAI_OBJECT_TYPE_ENI:oid:0x7200000000001e|SAI_ENI_ATTR_VNET_ID=oid:0x7900000000001d|SAI_ENI_ATTR_ADMIN_STATE=true|SAI_ENI_ATTR_VM_UNDERLAY_DIP=221.1.0.0|SAI_ENI_ATTR_VM_VNI=1
2024-06-11.15:44:31.845547|c|SAI_OBJECT_TYPE_ENI_ETHER_ADDRESS_MAP_ENTRY:{"address":"00:1A:C5:00:00:01","switch_id":"oid:0x21000000000000"}|SAI_ENI_ETHER_ADDRESS_MAP_ENTRY_ATTR_ENI_ID=oid:0x7200000000001e
2024-06-11.15:44:31.855380|C|SAI_OBJECT_TYPE_OUTBOUND_ROUTING_ENTRY||{"destination":"1.4.1.245/32","eni_id":"oid:0x7200000000001e","switch_id":"oid:0x21000000000000"}|SAI_OUTBOUND_ROUTING_ENTRY_ATTR_ACTION=SAI_OUTBOUND_ROUTING_ENTRY_ACTION_ROUTE_VNET_DIRECT|SAI_OUTBOUND_ROUTING_ENTRY_ATTR_DST_VNET_ID=oid:0x7900000000001d|SAI_OUTBOUND_ROUTING_ENTRY_ATTR_OVERLAY_IP=1.4.0.1||{"destination":"1.4.0.1/32","eni_id":"oid:0x7200000000001e","switch_id":"oid:0x21000000000000"}|SAI_OUTBOUND_ROUTING_ENTRY_ATTR_ACTION=SAI_OUTBOUND_ROUTING_ENTRY_ACTION_ROUTE_VNET|SAI_OUTBOUND_ROUTING_ENTRY_ATTR_DST_VNET_ID=oid:0x7900000000001d
2024-06-11.15:44:31.864969|C|SAI_OBJECT_TYPE_ROUTE_ENTRY||{"dest":"18.0.202.0/31","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000003"}|SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID=oid:0x600000000001c
2024-06-11.15:44:31.867401|c|SAI_OBJECT_TYPE_NEIGHBOR_ENTRY:{"ip":"18.0.202.0","rif":"oid:0x600000000001c","switch_id":"oid:0x21000000000000"}|SAI_NEIGHBOR_ENTRY_ATTR_DST_MAC_ADDRESS=<ANONIMIZER REMOVED>
2024-06-11.15:44:31.868672|c|SAI_OBJECT_TYPE_NEXT_HOP:oid:0x400000000001f|SAI_NEXT_HOP_ATTR_TYPE=SAI_NEXT_HOP_TYPE_IP|SAI_NEXT_HOP_ATTR_IP=18.0.202.0|SAI_NEXT_HOP_ATTR_ROUTER_INTERFACE_ID=oid:0x600000000001c
2024-06-11.15:44:31.870967|c|SAI_OBJECT_TYPE_ROUTE_ENTRY:{"dest":"18.0.202.1/32","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000003"}|SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION=SAI_PACKET_ACTION_FORWARD|SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID=oid:0x1000000000001
2024-06-11.15:45:00.721584|S|SAI_OBJECT_TYPE_ROUTE_ENTRY||{"dest":"0.0.0.0/0","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000003"}|SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION=SAI_PACKET_ACTION_FORWARD||{"dest":"0.0.0.0/0","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000003"}|SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION=SAI_PACKET_ACTION_FORWARD||{"dest":"0.0.0.0/0","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000003"}|SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID=oid:0x400000000001f
2024-06-11.15:45:06.016458|c|SAI_OBJECT_TYPE_ROUTE_ENTRY:{"dest":"221.0.0.1/32","switch_id":"oid:0x21000000000000","vr":"oid:0x3000000000003"}|SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION=SAI_PACKET_ACTION_FORWARD|SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID=oid:0x1000000000001

[kcudnik]

Sairedis.rec is savers in order that API is called in or haven't,.each API is called under muted się at given time only one single API is executed and recorded, so if you are seeing order like you are not expecting that means this is the order that or haven't executed it. Be aware that if your are loading config int appdb then or haven't is picking that up but execute that inorder that it will pick up forom selectable event, so not necessary in order it was put in appdb, so if there are many events waiting orhagent can pick that up in random order, that's because selectable event is implemented using system poll api

From recording you attached I see no problems with oids, so a given pod is created like vent, and then it's used in pa entry, that's correct order that vip entry does not have any dependency on previous objects so at this point everything is done correctly, only issue is as I described above that OA is picking config in random order and that's by design, and not fault of recording