[Bugs] NRF GET nf-instances handles optional parameters as mandatory

[GKnirps]

Describe the bug

In the NRF endpoint GET nf-instances, the optional parameters nf-type and limit are de-facto treated as mandatory.

If the limit-Parameter is missing, a 400 Bad Request is returned. If the limit parameter is present, but the nf-type` parameter is missing, an empty result list is returned.

To Reproduce

Steps to reproduce the behavior:

1. start a simple setup of free5gc
2. request GET http://<address>:port/nnrf-nfm/v1/nf-instances
3. request http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances?limit=10

Expected behavior

When called without limit, the request should return all NF-instances or at least use a non-zero default limit.
When called without nf-type, the request should not filter for NF type and return NFs of all types

curl output

As example, here is what a curl request returns for my setup. First the missing limit parameter:

$ curl 'http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances' -H 'accept: application/json'
{"title":"Invalid Parameter","status":400,"detail":"strconv.Atoi: parsing \"\": invalid syntax"}

Second: the missing nf-type-parameter:

$ curl 'http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances?limit=10' -H 'accept: application/json'
{"nfType":"","_link":{"item":null}}

In contrast to that, a working example:

$ curl 'http://10.100.200.4:8000/nnrf-nfm/v1/nf-instances?limit=10&nf-type=AMF' -H 'accept: application/json'
{"nfType":"AMF","_link":{"item":[{"href":"http://nrf.free5gc.org:8000/nnrf-nfm/v1/nf-instances/5cce9dfa-6dbc-489f-8c19-a76d5a07ac2a"}]}}

Environment (please complete the following information):

• free5GC Version: 3.1.1
• OS: Arch Linux
• Kernel version: 6.1.2-arch1-1
• go version: go-1.14.4
• c compiler version (Option): gcc version 12.2.0

System architecture (Option)

The setup is a relatively basic docker setup using docker compose. The purpose of this setup is playing around with free5gc and doing research.

Additional context

I took a look at the code (internal/context/management_data.go and internal/sbi/producer/nf_management.go) and it looks like the issue would be relatively easy to fix. If someone here agrees that this report is an issue, I would

1. check if the limit is present before trying to parse it
2. set no limit to the mongodb-request if it is not set
3. set no filter for the mongodb-request if nf-type is absent or empty

and make a pull-request.

[GKnirps]

I stand corrected: Fixing the issue for the limit parameter should be trivial, but fixing the nf-type parameter is a bit more work.