зеркало из https://github.com/mozilla/gecko-dev.git
95e9c477dd
The main goal of these changes is to ensure we're not doing any unnecessary work in the unahppy cases of BatchingUploader. We might fail in three general ways: - encounter a 412 error - encounter another type of HTTP error - encounter a GUID in the "failed" array Currently, in all of these cases, we de-facto abort the session, without performing an actual abort. E.g. we won't commit a batch, we'll refuse to upload any still-flowing records. This patch simplifies our unhappy-case behaviour: if something failed, actually abort the session (triggering a shutdownNow of the work queues), declare store as failed, etc. It's important to note that our "did the synchronization fail?" login in the SynchronizerSession depends on the store failure counts, and so this patch maintains the "record failed to store" delegate chain. However, these counts are largely meaningless. What does it mean to fail to store 50 records, if we abort on the 51st, and prevent the other 100 from flowing (and from being counted as failed?). This patch also fixes an omission in the verstion tracking logic: - prior, if we encountered a record in the "failed" array, we'd continue on with the flow, won't upload anything, mark the synchronization as failed, but we'd also call into 'onStoreCompleted' which will trigger an update of syncVersion for outflowing records - with this patch, we won't call into onStoreCompleted in the case above, and so won't update syncVersion in case of such failures - this is the correct behaviour for batching uploads (now enabled on all but one server), but possibly non-optimal behaviour if batching isn't enabled. However, this behaviour should be safe from a data consistency point of view regardless of the batching mode. MozReview-Commit-ID: LIYCPaRX8JA --HG-- extra : rebase_source : 110224b2db85a383635db933ec6c19b21af886e7 |
||
|---|---|---|
| .. | ||
| android | ||
| locales | ||