-
Notifications
You must be signed in to change notification settings - Fork 574
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
daemon, cmd/snapd: propagate context #14130
daemon, cmd/snapd: propagate context #14130
Conversation
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.
Little detail, not very important.
daemon/api_snaps.go
Outdated
@@ -145,6 +145,7 @@ func postSnap(c *Command, r *http.Request, user *auth.UserState) Response { | |||
return BadRequest("unknown action %s", inst.Action) | |||
} | |||
|
|||
// TODO use an epxlicit context parameter |
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.
typo
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.
thanks for catching, I've updated the patch
c87a81d
to
d57db28
Compare
Tested with snapd-desktop-integration. Seems to work as expected. (EDIT: at least after the last patch; before it crashed). |
Establish a cancelation chain for incoming API requests, to ensure orderly shutdown. This prevents a situation in which an API request, such as notices wait can block snapd shtudown for a long time. Signed-off-by: Maciej Borzecki <[email protected]>
Request's can be canceled based on the code actually issuing a cancel on the associted context, hence an Internal Server Error seems more appropriate. Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
Pass the context from the API request further down. Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
f80e7ce
to
f01e830
Compare
there were some conflicts in cmd/snapd/main.go, so I rebased on top of current master |
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.
LGTM
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.
I really like this, Thank you!
daemon/api_snaps.go
Outdated
@@ -882,7 +881,7 @@ func meetSnapConstraintsForEnforce(inst *snapInstruction, st *state.State, vErr | |||
return snapstateResolveValSetsEnforcementError(context.TODO(), st, vErr, pinnedSeqs, inst.userID) |
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.
Do we want to pass context here?
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.
thanks for spotting
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.
thanks, I think the changes need a bit more direct testing
daemon/daemon.go
Outdated
@@ -320,7 +321,7 @@ func (d *Daemon) initStandbyHandling() { | |||
} | |||
|
|||
// Start the Daemon |
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.
the doc comment should probably say something about ctx
defer func() { | ||
// cancel the context on any errors | ||
if err != nil { | ||
cancel() |
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.
we don't really have tests that show that is relevant, do we ?
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.
not really, but coverage shows this place is hit in TestHandleUnexpectedRestart test
@@ -482,6 +499,10 @@ func (d *Daemon) Stop(sigCh chan<- os.Signal) error { | |||
return fmt.Errorf("internal error: no Overlord") | |||
} | |||
|
|||
if d.cancel != nil { | |||
d.cancel() |
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.
this probably needs an explicit test in daemon_test.go
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.
I"ve added couple more tests that verify context cancelation and propagation, and one which hijacks d.cancel
Thanks to @ZeyadYasser Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
Signed-off-by: Maciej Borzecki <[email protected]>
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.
thank you, one test question
daemon/daemon_test.go
Outdated
// since the tests aren't in a package, we directly hijack d.cancel | ||
c.Assert(d.cancel, check.NotNil) | ||
cancel := d.cancel | ||
defer cancel() |
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.
I'm not entirely sure what this tests is about, shouldn't this check a bit more?
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.
I think I'll drop this one for now. The idea was to check that Stop() wouldn't call cancel if it's nil. Another way to trigger this would be to call Stop(), without a prior call to Start(), but we clearly do not support that and it segfaults on calling d.standbyOpinions.Stop()
.
The test isn't very useful. Another option to trigger this would be to call Stop() without a prior call to Start(), but this segfaults on d.standbyOpinions.Stop(), so it'c clear this needs a followup fix or callign Stop() this way isn't supported. Signed-off-by: Maciej Borzecki <[email protected]>
This is another take at #13961, but this time around the branch is attempting at a refactor of how the context is propagated and how it interacts with cancelation.
Related: SNAPDENG-22871