You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
https://mozilla-hub.atlassian.net/browse/SYNC-4221 will begin updating TTL records for every entry in the router column family so we can enable Bigtable’s garbage collection of router data. Under Bigtable, when updating the TTL (when a user conducts some form of activity) we need to first read the contents of that router row, then write the contents out again with new TTLs (cell timestamps).
We currently do not enforce any kind of limit of the number of channels (subscriptions) a user can have. Especially with the added work of needing to read all the channels out and then write them again with the new timestamp, we should begin enforcing some kind of maximum limit of channels to limit the work required. Also any user exceeding such a limit is likely either misconfigured or abusing our system.
The enforcement of the max should simply drop the user record, forcing them to recreate a fresh one.
Hrm. We could probably add a metric to the mobile channel check and the desktop “hello” to get an idea of the median number of channels a given UAID may have.
https://mozilla-hub.atlassian.net/browse/SYNC-4221 will begin updating TTL records for every entry in the router column family so we can enable Bigtable’s garbage collection of router data. Under Bigtable, when updating the TTL (when a user conducts some form of activity) we need to first read the contents of that router row, then write the contents out again with new TTLs (cell timestamps).
We currently do not enforce any kind of limit of the number of channels (subscriptions) a user can have. Especially with the added work of needing to read all the channels out and then write them again with the new timestamp, we should begin enforcing some kind of maximum limit of channels to limit the work required. Also any user exceeding such a limit is likely either misconfigured or abusing our system.
The enforcement of the max should simply drop the user record, forcing them to recreate a fresh one.
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: