Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: make the worker handoff write path cancellable #1237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
feat: make the worker handoff write path cancellable #1237
Changes from all commits
ee5188f83eb67d12469c3f18303c287bbbe8510251822f1665e7080b080a917768d5bfb833fd9ada2035db2f755247f10e4e08e19File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. Fixed in
822f166c.Deriving the deletion timeout from the signal context is what created it: before this branch
removeImagesbuilt its own budget fromcontext.Background(), so cancellation could not reach it and could not be misreported by it. Once it can,nilfromremoveImagesstops meaning "the images are gone".mainnow refuses to treat the removal as successful without checking:I took your fallback rather than the first suggestion deliberately, because the two are at different layers and this PR only owns one of them. Returning the context error from inside the delete branches also stops the loop early, which is a behavior change to the removal loop itself; the stacked #1239 makes it, with the tests for it, because that PR is what gives each deletion its own budget and therefore has to distinguish "this image ran out of time, carry on" from "the caller is gone, stop". Here the only defect is the exit status, so that is all that changes: an interrupted run still walks the remaining list logging instant failures, but it can no longer exit 0 while doing it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct — the coverage was theatre. Fixed in
768d5bfc.Every case in
TestRemoveImagespasses a context that is never done, and the fake discarded the argument outright, so revertingcontext.WithTimeout(ctx, timeout)tocontext.WithTimeout(context.Background(), timeout)left the suite green. That is the one thing this hunk exists to do.The fake now observes its context, which is what a real client does anyway, and the propagation is pinned by behavior rather than by inspection:
Against
context.Background()it reportsremoved = 1, want 0andthe image was deleted for a caller that was already gone.I went with an already-cancelled caller rather than the blocking fake you suggested, because a blocking fake asserts that cancellation unblocks
removeImages, and here nothing blocks —DeleteImageis a call, not a wait, and the loop has no guard in this PR. The question this hunk raises is narrower: does the runtime see the caller's context or a detached one. An already-dead context answers exactly that, without inventing a blocking behavior the real CRI client doesn't have.Worth flagging for when you look at the stacked #1239: it adds a guard that returns before the loop reaches the runtime at all, which makes this test assert the wrong thing there, so it is removed in the commit that introduces the guard. The propagation stays covered there by
TestRemoveImagesSurfacesCancellationDuringTheFinalDeletion, which cancels during a deletion and so still requires the runtime to be holding the caller's context.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should
context.Canceledstop the deletion loop immediately? At present it is handled like an ordinary per-image error, so every remainingDeleteImagecall is attempted beforemainnotices cancellation. Could we return the context error here and in the prune loop?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, and it exists — in the stacked #1239, with tests. Two commits there do exactly what you describe:
085dc1cadds the guard to the top of both loops, so a cancelled caller stops rather than walking the rest of the list588635dhandles the case the guard can't see: cancellation during the last deletion, where there is no later iteration to reach the guardThe split was deliberate but I'm now the only one who thinks so, which is usually the sign it was wrong. My reasoning was that returning the context error from inside the delete branches changes the loop's behaviour, and #1239 is the PR that has to distinguish "this image ran out of its own budget, carry on" from "the caller is gone, stop" — because it's the one that gives each deletion a budget. Here, without per-image budgets, the only defect is the exit status, so that's all I changed:
mainchecksctx.Err()afterremoveImagesand exits non-zero, which stops an interrupted run reporting success even though it still walks the remaining list.You're the second reviewer to raise it against this PR, so if you'd rather #1237 not merge without the early stop, say so and I'll move both hunks down here and rebase #1239 on top. It's a contained change; I just didn't want to duplicate it across two open PRs on my own initiative.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.