Open Bug 1330045 Opened 8 years ago Updated 1 year ago

Full re-download of history results in a full re-upload

Categories

(Firefox for iOS :: Data Storage, defect, P3)

Product:
Firefox for iOS
Component:
Data Storage
Platform:
All
iOS
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
fxios 10.0 ---

People

(Reporter: rnewman, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MobileCore][Sync]) 

Part of Bug 1328123.

My device re-downloaded 80,000 records, applying them one by one to a dirty DB:

```
2017-01-02 09:09:46.792 [Debug] [SQLiteHistory.swift:911] insertOrUpdatePlace(_:modified:) > Warning: history item WHYYzJNZRRh2 changed both locally and remotely. Comparing timestamps from different clocks!
…
2017-01-02 09:21:38.564 [Debug] [Downloader.swift:192] handleSuccess > Advancing baseTimestamp to 1483345007450 - 1
2017-01-02 09:21:38.565 [Debug] [Downloader.swift:204] handleSuccess > Advancing lastModified to Optional(1483345007450) ?? 1483345007450.
2017-01-02 09:21:38.572 [Debug] [BrowserDB.swift:306] checkpoint() > Checkpointing a BrowserDB.
```

Then the horror:

```
[HistorySynchronizer.swift:174] uploadOutgoingFromStorage(_:lastTimestamp:withServer:) > Uploading 84852 modified places.
```

This should be easy enough to repro on a custom build: set up Sync with some data, sync, then call reset locally to flip the last fetch timestamp to zero. Expected behavior is that all server records are re-downloaded, but none are flagged to upload.
Priority: P2 → P3
Rank: 2
Whiteboard: [MobileCore] → [MobileCore][Sync]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --

The severity field is not set for this bug.
:jeevans, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jeevans)
You need to log in before you can comment on or make changes to this bug.