Hi @jseba. 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.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 5m 47s (non-voting)

I'd like to silence this log message

Why?

The three places where this happens will already return a context.Canceled error, which bubbles up to the API caller.

This is not true if the cancel occurs during executing Remove.

The following also doesn't bubble up "context cancelled" error.

		if diff.Digest != diffIDs[i] {
			abort()
			return errors.Errorf("wrong diff id calculated on extraction %q", diffIDs[i])
		}

I'd like to silence this log message

Why?

When using the client API, if our process gets a SIGINT, we cancel the context and handle the errors that result from that. However, we're getting this extra log message that shows up in our metrics as an extra error.

I would like to be able to handle this error in our process but I'm not seeing a way to do that other than just silencing it. I'm open to any suggestions to implement something that allows the caller to receive this error and decide what to do with it.

The three places where this happens will already return a context.Canceled error, which bubbles up to the API caller.

This is not true if the cancel occurs during executing Remove.

The following also doesn't bubble up "context cancelled" error.

		if diff.Digest != diffIDs[i] {
			abort()
			return errors.Errorf("wrong diff id calculated on extraction %q", diffIDs[i])
		}

Ah, I missed that, thanks for pointing that out. I was definitely thinking this seemed on the fragile side and wasn't sure what machinery and other things I was missing.

It may be more appropriate to change this to Warn. It is relevant information that the snapshot was not removed, whether or not that is because it was cancelled does not change the value of that information. I agree it does not need to be considered an error since the snapshot may be removed by other means. However, until it is removed, that key is unavailable and this log indicates that.

Handled in #7859