-
Notifications
You must be signed in to change notification settings - Fork 74
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?
Changes from all commits
ee5188f
83eb67d
12469c3
f18303c
287bbbe
8510251
822f166
5e7080b
080a917
768d5bf
b833fd9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,10 +8,13 @@ import ( | |
| util "github.com/eraser-dev/eraser/pkg/utils" | ||
| ) | ||
|
|
||
| func removeImages(c cri.Remover, targetImages []string) (int, error) { | ||
| func removeImages(ctx context.Context, c cri.Remover, targetImages []string) (int, error) { | ||
| removed := 0 | ||
|
|
||
| backgroundContext, cancel := context.WithTimeout(context.Background(), timeout) | ||
| // Derived from the caller's context, not Background: signal notification is | ||
| // registered for the whole process, so nothing would observe a SIGTERM during | ||
| // the deletion loop otherwise. | ||
| backgroundContext, cancel := context.WithTimeout(ctx, timeout) | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct — the coverage was theatre. Fixed in Every case in 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: func TestRemoveImagesPassesTheCallersContextToTheRuntime(t *testing.T) {
ctx, cancel := context.WithCancel(context.Background())
cancel()
client := &testClient{t: t, images: []*v1.Image{{Id: "sha256:aaaa"}}}
removed, err := removeImages(ctx, client, []string{"sha256:aaaa"})
...
}Against I went with an already-cancelled caller rather than the blocking fake you suggested, because a blocking fake asserts that cancellation unblocks 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 |
||
| defer cancel() | ||
|
|
||
| images, err := c.ListImages(backgroundContext) | ||
|
|
||
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.