Hi @gabriel-samfira. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/ok-to-test

Build succeeded.

• containerd-build-arm64 : RETRY_LIMIT in 3m 41s (non-voting)
• containerd-test-arm64 : RETRY_LIMIT in 6m 01s (non-voting)
• containerd-integration-test-arm64 : RETRY_LIMIT in 24m 36s (non-voting)

@dcantah - I thought this was already solved by parallel reconnect?

@dcantah - I thought this was already solved by parallel reconnect?

Is this PR just Containerd on Windows takes > 2 seconds to startup and that's failing the test? I'd done some work to try reconnecting any task IO if containerd restarted, but not sure this is the reason for the failure in this test. https://github.com/microsoft/hcsshim/blob/master/internal/cmd/io_npipe.go#L77-L159

Is this PR just Containerd on Windows takes > 2 seconds to startup and that's failing the test?

Yes,

I'd done some work to try reconnecting any task IO if containerd restarted, but not sure this is the reason for the failure in this test.

It hink it's just a matter of timing. The wait time is just 2 seconds. If containerd takes longer to start on Windows, the test will fail. It's not an issue with hcsshim. The client tries to reconnect to containerd within 2 seconds after restart and sometimes (not always) fails.