Description
Within containerd's current design, if the shim is killed before task-service.Delete API call, the callback on connect close will send 137 exit code because the callback doesn't have any context about container's exit code.
https://github.com/containerd/containerd/blob/70a2c95ae8c02d7a4e448f0e4fb8bb0e6344b5c7/runtime/v2/shim.go#L170-L184
And the moby/moby can't handle duplicate exit event well. Let's say that the moby receives exit code 0 at first and then the duplicate exit event with different code 137 can override 0, as the containerd/containerd#4769 described.
And the containerd task events are best-effort mode because there is no cache and it's handled by shim. I think it's hard to guarantee the exit status is correct. So, I suggest to use task.Wait API instead of event.
REF: containerd/containerd#8954
Description
Within containerd's current design, if the shim is killed before task-service.Delete API call, the callback on connect close will send 137 exit code because the callback doesn't have any context about container's exit code.
https://github.com/containerd/containerd/blob/70a2c95ae8c02d7a4e448f0e4fb8bb0e6344b5c7/runtime/v2/shim.go#L170-L184
And the moby/moby can't handle duplicate exit event well. Let's say that the moby receives exit code 0 at first and then the duplicate exit event with different code 137 can override 0, as the containerd/containerd#4769 described.
And the containerd task events are best-effort mode because there is no cache and it's handled by shim. I think it's hard to guarantee the exit status is correct. So, I suggest to use task.Wait API instead of event.
REF: containerd/containerd#8954