1157527 - Consider altering the TTL for client records

Status: NEW

(Firefox for iOS :: Sync, defect)

Description

[Richard Newman [:rnewman]]

See discussion:

https://github.com/mozilla/firefox-ios/pull/356#commitcomment-10854170
https://github.com/mozilla/firefox-ios/pull/356#commitcomment-10857727

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

Is there discussion in those links? Or has github buried it so deeply it's not easy to find?

Comment 2

[Richard Newman [:rnewman]]

Oh joy, you can't deeplink commit comments across a rebase. I thought they fixed that?

nalexander:
---
This has been a bugbear for ages. Let's reduce this, a lot, and upload our client record more frequently too.
---

me:
---
I don't think reducing it is necessarily the right approach. It's three weeks so that, when you go on vacation for two weeks and want to send tabs to your desktop before the flight home, your desktop still appears in the list!

I agree with uploading more frequently, but the TTL here will always be a bad compromise.
---



The compromise here: a shorter TTL means that dead clients disappear sooner, but a shorter TTL means that live clients will occasionally disappear just because they haven't synced recently.

For example, I rarely boot my Windows machine; if I haven't used it in the past three weeks, I can't see its tabs or send pages to it. If we dropped the TTL to one week, none of my tablets would show up, either.

This (as I note in the comment above) is particularly significant when traveling, which is a big first-world use case for task continuity.

In the very very worst case:

  Day 0: leave on trip.
  Day 1: send a tab to your desktop.
  Day 22: desktop's client record, complete with sent tab, is TTLed.
  Day 23: get home. Sent tab will never arrive, because the record was deleted by the server!

Compare that to the downside of a long TTL: when you lose a phone, it'll stick around in your lists for weeks.