Skip to content

nerdctl inspect response responds to DevContainers with null values #3310

@chews93319

Description

@chews93319

Description

When using VSCode DevContainers with finch to re-open a "workspace within a container" (after successfully opening "workspace within a container" once and exiting), the "DevContainers Log" reports the following error: TypeError: Cannot read properties of null (reading 'Ports').

After some investigation, we observed two scenarios with finch using nerdctl:

  1. When a container is launched without a published port, the response of nerdctl inspect --mode=dockercompat omits the Ports key-value pair from the NetworkSettings.
  2. When nerdctl inspect --mode=dockercompat inspects an "Exited" container, the NetworkSettings key contains a null value.

Compared to the Docker scenarios:

  1. When a container is launched without a published port, the response of docker inspect, the Ports key-value pair is present within NetworkSettings entity, but the value is an empty structure.
  2. When docker inspect inspects an "Exited" container, the NetworkSettings key contains a complete structure of expected keys, all with "zero-value" values.

This bug affects integration of VSCode DevContainers with finch because DevContainers expects the complete NetworkSettings structure with all "zero-value" members for both of the scenarios.

Steps to reproduce the issue

Scenario 1: Container without published ports returns NetworkSettings without Ports entity

  1. Using finch, launch a container with specified ports
    a. finch run -p 8080:80 -d alpine:latest sleep infinity, which invokes nerdctl run -p 8080:80 -d alpine:latest sleep infinity
  2. Inspect the container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  3. Confirm the presence of Ports entity within NetworkSettings struct
    "NetworkSettings": {
        "Ports": {
            "80/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "8080"
                }
            ]
        },
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "10.4.0.9",
        "IPPrefixLen": 24,
        "MacAddress": "xx:xx:xx:xx:xx:xx",
        "Networks": {
            "unknown-eth0": {
                "IPAddress": "10.4.0.9",
                "IPPrefixLen": 24,
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "xx:xx:xx:xx:xx:xx"
            }
        }
    }
    
  4. Create another container without a published port
    a. finch run -d alpine:latest sleep infinity, which invokes nerdctl run -d alpine:latest sleep infinity
  5. Inspect the new container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  6. Confirm the lack of presence of Ports entity within NetworkSettings struct
    "NetworkSettings": {
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "10.4.0.10",
        "IPPrefixLen": 24,
        "MacAddress": "xx:xx:xx:xx:xx:xx",
        "Networks": {
            "unknown-eth0": {
                "IPAddress": "10.4.0.10",
                "IPPrefixLen": 24,
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "xx:xx:xx:xx:xx:xx"
            }
        }
    }
    

Inspecting an Exited Container

  1. Using finch, launch a container with specified ports
    a. finch run -p 8070:70 -d alpine:latest sleep infinity, which invokes nerdctl run -p 8070:70 -d alpine:latest sleep infinity
  2. Inspect the container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  3. Confirm the presence of Ports entity within NetworkSettings struct
  4. Stop the container
    a. finch container stop <container_id>, which invokes nerdctl container stop <container_id>
  5. Inspect the container to verify response payload
    a. finch inspect --mode=dockercompat <container_id>, which invokes nerdctl inspect --mode=dockercompat <container_id>
  6. Confirm the null value of NetworkSettings struct
    "NetworkSettings": null
    

Describe the results you received and expected

For the "container with published port", the NetworkSettings includes the expected Ports struct and all appropriate information. This is already successful and should be maintained during any changes.

The expected results should be as follows for the two scenarios:

  1. When a container is launched without a published port, the response of nerdctl inspect --mode=dockercompat should include the Ports key-value pair within the NetworkSettings with a value of { }.
  2. When nerdctl inspect --mode=dockercompat inspects an "Exited" container, the NetworkSettings key should map to a struct containing all keys mapping to "zero-value" values.

What version of nerdctl are you using?

Observed behavior with both:
- Local build from branch release/1.7
- Local build from branch main

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

None

Host information

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions