invalid JSON: got EOF while reading request body when executing CommitContainerChanges

[kevinboss]

Output of dotnet --info:

.NET SDK:
 Version:   7.0.203
 Commit:    5b005c19f5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.203\

Host:
  Version:      7.0.5
  Architecture: x64
  Commit:       8042d61b17

.NET SDKs installed:
  5.0.408 [C:\Program Files\dotnet\sdk]
  6.0.408 [C:\Program Files\dotnet\sdk]
  7.0.203 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.16 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

What version of Docker.DotNet?:

3.125.14

Steps to reproduce the issue: Execute CommitContainerChanges with Docker Desktop for Windows, Version 4.19.0 (106363) with the following parameters:

• ContainerID: Id of a running container
• RepositoryName: mcr.microsoft.com/mssql/server
• Tag: 2019-CU15-ubuntu-20.04-20230502040827

What actually happened?:

What did you expect to happen?: New image is created from running container

Additional information: I feel like it worked up until the last Docker Desktop update (this is only a hunch however).

[kevinboss]

After downgrading to 4.18 everything seems to work once again. I have however not enough knowledge with the docker API to understand if this is related to an Issue in the Library or Docker itself.

[HofmeisterAn]

I do not know why it fails for the latest version, but I think (guess) the generated model (CommitContainerChangesParameters) is wrong. If you compare the /containers/create and the /commit API endpoint, you will notice that Docker.DotNet defines the models different.

While CreateContainerParameters annotates all query parameters and request body properties, CommitContainerChangesParameters does not. The request body Config is a nested type and I think that might be wrong.

Could you please check the HTTP request that Docker.DotNet creates and sends? This should help us understand the issue.

Maybe it is a regression or a change in the latest release of Moby, which is included in Docker Desktop 4.19.0.

[kevinboss]

I have debugged HttpConnection. Docker.DotNet sends

POST /commit?container=939eab072cd3cb77123d178c78ed872fe36194fde949ffd737c330198b2ee95f&repo=docker%2Fgetting-started&tag=latest-20230510102730 HTTP/1.1 User-Agent: Docker.DotNet Host: docker_engine:80 Connection: close

and gets

HTTP/1.1 400 Bad Request Api-Version: 1.42 Content-Type: application/json Date: Wed, 10 May 2023 20:29:25 GMT Docker-Experimental: false Ostype: linux Server: Docker/23.0.5 (linux) Connection: close Transfer-Encoding: chunked

in return.

My issue is fixed however, as soon as I set Config to new Config everything works fine. Maybe the fallback here should be an empty object instead of null?

[aaronasmith]

Is this fixed in the library, or is this just a workaround? I ran into this today and used this workaround as well and it works. I feel like if this hasn't been fixed it shouldn't have been closed.

[kevinboss]

Is this fixed in the library, or is this just a workaround? I ran into this today and used this workaround as well and it works. I feel like if this hasn't been fixed it shouldn't have been closed.

I added PR#636