VRF: opi-evpn-bridge-opi-evpn-bridge container crashes when trying to create Vrf

[vikumarks]

GRPC server LOG:
github.com/opiproject/opi-evpn-bridge/pkg/vrf.(*Server).CreateVrf(0x40000b7630, {0x8c7ed0, 0x400027fb90}, 0x40001ff580) /app/pkg/vrf/grpc.go:65 +0x318 github.com/opiproject/opi-api/network/evpn-gw/v1alpha1/gen/go._VrfService_CreateVrf_Handler.func1({0x8c7ed0, 0x400027fb90}, {0x742880?, 0x40001ff580}) /go/pkg/mod/github.com/opiproject/opi-api@v0.0.0-20231120071940-7b62be4a63bd/network/evpn-gw/v1alpha1/gen/go/l3_xpu_infra_mgr_grpc.pb.go:151 +0x74 github.com/grpc-ecosystem/go-grpc-middleware/v2/interceptors/logging.UnaryServerInterceptor.UnaryServerInterceptor.func2({0x8c7ed0, 0x400027e6c0}, {0x742880, 0x40001ff580}, 0x40004ad9e8?, 0x40000ab9b0) /go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware/v2@v2.0.1/interceptors/server.go:22 +0x1f0 github.com/opiproject/opi-api/network/evpn-gw/v1alpha1/gen/go._VrfService_CreateVrf_Handler({0x77ea20?, 0x40000b7630}, {0x8c7ed0, 0x400027e6c0}, 0x400018db80, 0x40000ab038) /go/pkg/mod/github.com/opiproject/opi-api@v0.0.0-20231120071940-7b62be4a63bd/network/evpn-gw/v1alpha1/gen/go/l3_xpu_infra_mgr_grpc.pb.go:153 +0x12c google.golang.org/grpc.(*Server).processUnaryRPC(0x400021a3c0, {0x8c7ed0, 0x400027e5a0}, {0x8cc698, 0x400040e820}, 0x4000242ea0, 0x400022ff80, 0xdbb460, 0x0) /go/pkg/mod/google.golang.org/grpc@v1.59.0/server.go:1343 +0xb8c google.golang.org/grpc.(*Server).handleStream(0x400021a3c0, {0x8cc698, 0x400040e820}, 0x4000242ea0) /go/pkg/mod/google.golang.org/grpc@v1.59.0/server.go:1737 +0x988 google.golang.org/grpc.(*Server).serveStreams.func1.1() /go/pkg/mod/google.golang.org/grpc@v1.59.0/server.go:986 +0x88 created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 89 /go/pkg/mod/google.golang.org/grpc@v1.59.0/server.go:997 +0x160

[Priyanshu-u07]

Tried to reproduce on current main using the repo's docker-compose setup. CreateVrf no longer crashes the container. It completes and the gRPC server stays healthy (status went PENDING to UP, lgm/frr components SUCCESS). Looks like the VRF reconciliation refactor resolved the panic. Couldn't trigger the crash with repeated calls either.

Possibly safe to close. Happy to share full repro steps/logs if needed.