609395 - Make tracking changedIDs obsolete for most cases

Status: RESOLVED WONTFIX

(Firefox :: Sync, defect)

Description

[Philipp von Weitershausen [:philikon]]

All data types we sync have associated modified timestamps. That means we can just remember the last time we synced, have trackers only track dirty state as a boolean flag, and then do range queries to find the items that were modified sync the last time.

As an upgrade step, we read changedIDs one last time and use that to sync. From that point on we save a local timestamp as a pref every time we sync and use the range queries.

Comment 1

[Philipp von Weitershausen [:philikon]]

One thing we need to make sure is that upload errors are still handled, e.g. if the server responds with a list of GUIDs that it couldn't store, these need to be uploaded again. Bug 591126 plays into this, too.

Comment 2

[Philipp von Weitershausen [:philikon]]

(In reply to comment #1)
> One thing we need to make sure is that upload errors are still handled, e.g. if
> the server responds with a list of GUIDs that it couldn't store, these need to
> be uploaded again. Bug 591126 plays into this, too.

Just discussed this with Toby. The server should 503 if there's something wrong with the database and the records weren't written. In that case we abort already. The only time we ever get back a list of failed record IDs is when records themselves were malformed. I think in that case something's wrong with Sync anyway, so we might as well just abort in that case, too.

However, Toby raised a good point: the timestamp approach won't let us track deletes. So we'll still need the trackers around for deletes. It'll be much less I/O and it will only occur when deletes are happening for a particular engine.

Comment 3

[Philipp von Weitershausen [:philikon]]

(In reply to comment #2)
> The only time we ever get back a list of failed record IDs is when
> records themselves were malformed. I think in that case something's wrong with
> Sync anyway, so we might as well just abort in that case, too.

Since we need to keep trackers around anyway, we can mark the failed items in the tracker and continue silently, but we should log the incident on the server. Filed bug 610827 for that.

Comment 4

[Philipp von Weitershausen [:philikon]]

Morphing this bug slightly: We'll still track changedIDs, but only in the following cases:

* deletes
* individual records failed to upload
* timestamps for the specific record type (e.g. passwords, form data) aren't available (Firefox 3.5/3.6)

Comment 5

[Mike Connor [:mconnor]]

Anything left to do here?  Reopen if so.

Comment 6

[Philipp von Weitershausen [:philikon]]

(In reply to Mike Connor [:mconnor] from comment #5)
> Anything left to do here?  Reopen if so.

Technically this was never done and we still want to do it. But not in the old engine/store/tracker world. So yeah marking this as WONTFIX.