Default behaviour of JSON marshalling for nil slices?

[gesellix]

tl;dr: Should nil Golang slices always be returned as JSON [] on the api?

Description

The current swagger api docs declare most slices and objects as non-nullable arrays. Some properties are marshalled to JSON null when the Golang slice ro struct is nil. See #42607 for an example.

I'm also working on a modified hack copy at https://github.com/docker-client/docker-engine/blob/main/engine-api-model/docker-engine-api-v1.41.yaml, and I would like to apply my custom fixes upstream. I'm uncertain in which direction a fix should be made, considering the following options:

1. Declare properties as x-nullable: true where the runtime returns JSON null.
2. Fix the Moby api to change nil slices to return an empty JSON array [].
3. ...?

Here's the current list of properties where I found a mismatch between the 1.41 api swagger docs and the actual api. Please consider this list as work-in-progress:

1. ImageSummary.RepoTags (array, should be JSON [] on the api)
2. ImageSummary.RepoDigests (array, should be JSON [] on the api)
3. ImageSummary.Labels (object, should be declared x-nullable:true)
4. Volume.Labels (object, should be declared x-nullable:true)
5. Volume.Options (object, should be declared x-nullable:true)
6. VolumeListResponse.Warnings (array, should be JSON [] on the api)

Additional information you deem important (e.g. issue happens only occasionally):

Articles like https://medium.com/swlh/arrays-and-json-in-go-98540f2fa74e provide some ideas, yet, each with a tradeoff.

Output of docker version:

Client:
 Cloud integration: 1.0.17
 Version:           20.10.7
 API version:       1.41
 Go version:        go1.16.4
 Git commit:        f0df350
 Built:             Wed Jun  2 11:56:22 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.7
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       b0f5bc3
  Built:            Wed Jun  2 11:54:58 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  compose: Docker Compose (Docker Inc., v2.0.0-beta.6)
  scan: Docker Scan (Docker Inc., v0.8.0)
WARNING: Plugin "/Users/tobias.gesellchen/.docker/cli-plugins/docker-app" is not valid: failed to fetch metadata: fork/exec /Users/tobias.gesellchen/.docker/cli-plugins/docker-app: no such file or directory

Server:
 Containers: 7
  Running: 0
  Paused: 0
  Stopped: 7
 Images: 31
 Server Version: 20.10.7
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc version: b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.25-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 3
 Total Memory: 3.598GiB
 Name: docker-desktop
 ID: JSX5:FY4X:SLKH:SJVC:KL7I:6YRO:HODA:G7ZV:F5MK:5WFS:Y6DJ:UXVT
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

[gesellix]

Trying to get some attention... Did anyone notice this issue? Should I start with a pull request containing the changes described above?