Snap refresh over metered connections

Looks like it would be beneficial to split the case when connection if explicitly marked as metered from the case when it’s a guess. I’ve put this down in a table.

Can we refresh?

  • x yes
  • - no
                                    (NetworkManager value)
| device  | setting                | NO | GUESS_NO | GUESS_YES | YES |
|---------+------------------------+----+----------+-----------+-----|
| classic | force                  | x  | x        | x         | x   |
| classic | hold                   | x  | x        | x         | -   |
| classic | hold-guessed           | x  | x        | -         | -   |
| classic | default (hold-guessed) | x  | x        | -         | -   |
|---------+------------------------+----+----------+-----------+-----|
| core    | force                  | x  | x        | x         | x   |
| core    | hold                   | x  | x        | x         | -   |
| core    | hold-guessed           | x  | x        | -         | -   |
| core    | default (hold)         | x  | x        | x         | -   |
  • hold-guessed (strawman atm) could be the new value that we add, which indicates that the refreshes are held when connection is implicitly marked as metered
  • hold is only effective when connection is explicitly marked as metered
  • classic systems default to hold-guessed
  • core systems default to hold

A hypothetical edge case, when a core system has a connection explicitly marked as metered with the intention of the setting being used by another application but would still like to receive snap updates would need to be updated to use refresh.metered=force.

1 Like