o/snapstate: only create link-component tasks when needed - #16882
Conversation
8d4ec22 to
9aaf098
Compare
|
Thu May 7 14:26:45 UTC 2026 Failures:Preparing:
Executing:
Restoring:
Skipped tests from snapd-testing-skipIf you wish to have any of the below tests run in your PR, in your PR description, add 'unskip:' followed by a copy-and-pasted list (without variants) of the below tests you wish to run (unskip plus test list must be valid yaml)
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #16882 +/- ##
==========================================
- Coverage 79.06% 79.05% -0.01%
==========================================
Files 1374 1381 +7
Lines 191076 191188 +112
Branches 2465 2465
==========================================
+ Hits 151065 151148 +83
- Misses 30918 30941 +23
- Partials 9093 9099 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
9aaf098 to
a39c311
Compare
|
This is rebased off of master now, and ready for review. |
alfonsosanchezbeato
left a comment
There was a problem hiding this comment.
Thanks, couple of questions
| return false | ||
| } | ||
|
|
||
| return cs.CompType == cc.compsup.CompType && *cs.SideInfo == *cc.compsup.CompSideInfo |
There was a problem hiding this comment.
Is it really necessary to consider here the type as well? It seems that CompSideInfo would be unique already.
There was a problem hiding this comment.
Yeah, prob don't need it. Removed.
| // when refreshing to the current snap revision, component refreshes | ||
| // rely on unlink-current-component/link-component. thus, undo can | ||
| // restore the old component revision cleanly. | ||
| return false |
There was a problem hiding this comment.
Question, but is then necessary to have the link/unlink component task? Or is it just harmless, but unneeded?
There was a problem hiding this comment.
this could be installing a new component as well? and then is needed, maybe the comment should also mention the install POV and not just the refresh POV?
There was a problem hiding this comment.
I updated the comments here, hopefully better now?
pedronis
left a comment
There was a problem hiding this comment.
did a pass, couple of comments and questions
| if !cc.snapsup.Revert { | ||
| // finalize (sets SnapState). if we're reverting, there isn't anything to | ||
| // change in SnapState regarding the component | ||
| if !cc.targetSnapAlreadyHasComponentRevision() { |
There was a problem hiding this comment.
is this equivalent also to !snapup.Revert because for the revert case we have made sure the revision is present already at this stage?
There was a problem hiding this comment.
Yes, this condition is essentially a super-set of the original revert condition.
| // when refreshing to the current snap revision, component refreshes | ||
| // rely on unlink-current-component/link-component. thus, undo can | ||
| // restore the old component revision cleanly. | ||
| return false |
There was a problem hiding this comment.
this could be installing a new component as well? and then is needed, maybe the comment should also mention the install POV and not just the refresh POV?
alfonsosanchezbeato
left a comment
There was a problem hiding this comment.
LGTM, thanks for the changes
5a3904d to
0ab511e
Compare
0ab511e to
5ebb091
Compare
c64f4f8 to
442dc65
Compare
This resolves an issue that happens on the undo path of a refresh to an already existing snap revision that happened to have some components. Assume this sequence in the state: snap-a+one+two at revision 1 <- previous snap-a+one+two at revision 2 <- current Then, the user refreshes snap-a+one+two back to the still-local revision 1: $ snap refresh snap-a --revision=1 In that scenario, we were creating link-component tasks for the already linked components one and two. The undo of this refresh would result in the sequence: snap-a at revision 1 <- previous, missing components because of undone link-component tasks snap-a+one+two at revision 2 <- current
442dc65 to
60533d3
Compare
This resolves an issue that happens on the undo path of a refresh to an already existing snap revision that happened to have some components.
Assume this sequence in the state:
Then, the user refreshes snap-a+one+two back to the still-local revision 1:
In that scenario, we were creating link-component tasks for the already linked components one and two. The undo of this refresh would result in the sequence: