### What needs to get done Issue a warning when snapcraft edit-validation-sets <account-id> <set-name> <sequence> is used to modify an assertion without incrementing the sequence number. **BEHAVIOR:** The warning should highlight that: - if anything goes wrong with an intended snap refresh, snap will not automatically revert to a valid state, the validation set state will become and remain invalid. - if the validation set specifies e.g. a revision that exists in the store and is not available on the architecture it will still refresh the validation set and become invalid without warning. Perhaps something like: `WARNING: not incrementing the sequence number means invalid changes or snap refresh failure will invalidate this assertion with no means to automatically revert to a valid state` Provide the opportunity to edit again, as is already the case with store error **APPROACH:** I am aware this can in theory be solved by the store as well, leaving it up to snapcraft team to decide on preferred approach. ### Why it needs to get done This request stems from an investigation into unexpected behavior observed by an early adopter of the validation-sets feature, as reported in SF. The outcome led us to re-evaluate the implications of making changes within incrementing assertion sequence number: When a device is pinned to an enforced and valid validation set at sequence <n>, subsequent mutation of the SAME SEQUENCE via `snapcraft edit-validation-sets <account-id> <set-name> <n>`, on refresh, can cause transition to invalid state due to things like: - refresh failure combined with inability to revert due to non-distinct sequence - revision of the correct snap but for a different architecture which is not store checked during submission The general idea/promise with enforced pinned validation sets are: `An assertion will move to the latest sequence if present in the store and if the installed snaps, including any newer revisions in the store, still satisfy their respective validation set assertions.` (https://snapcraft.io/docs/validation-sets) So at a sequence level it guards against actions that will cause transition to invalid. This is not the case with sub-sequence changes, which presents the real danger of accidentally invalidating a managed fleet.