Does the refresh.timer setting affect cohort expiration?

The help for snap create-cohort states:

Installations or refreshes of the snap using a given cohort key would use a fixed revision for up to 90 days, after which a new set of revisions would be fixed under that same cohort key and a new 90 days window started.

How does that interact with the refresh.timer setting? I can see three possibilities:

  • The expiration window is shortened if that setting is used, with cohorts expiring based on the set schedule rather than at 90 days

  • The expiration window stays the same, with cohorts expiring after 90 days but the actual refresh then being scheduled after that point per the setting

  • The setting is ignored entirely for cohorts, with cohorts expiring after 90 days and the snap being refreshed immediately at that point

1 Like

The two mechanisms are largely independent: a cohort influences which revision the store gives a client, while refresh.timer controls when a client asks the store for a potential new revision.

I think this is closest to your second possibility: refresh.timer is irrelevant within the initial 90 day period, because the store will always return the same revision, but after that period you’ll get the new revision the first time refresh.timer is satisfied.

1 Like