1484968 - Sync errors: extension-storage fails with "Insufficient Storage"

Status: RESOLVED FIXED

(WebExtensions :: Storage, defect, P3)

Description

[Nicolas Chevobbe [:nchevobbe]]

It's been a couple weeks now since I'm getting those sync errors notifications.
I see the following in the latest error-sync-*.txt file: 

> Sync.Engine.Extension-Storage	ERROR	Syncing [e-mail]: request failed: Error: HTTP 507 Insufficient Storage: Resource access is forbidden for this user (Maximum bytes per object exceeded (17319 > 16384 Bytes.)(resource://services-common/kinto-http-client.js:2341:5) JS Stack trace: [e-mail]:2341:5
> [e-mail]:2469:13
> Sync.Engine.Extension-Storage	WARN	Syncing failed: Error: HTTP 507 Insufficient Storage: Resource access is forbidden for this user (Maximum bytes per object exceeded (17319 > 16384 Bytes.)(resource://services-common/kinto-http-client.js:2341:5) JS Stack trace: [e-mail]:2341:5
> [e-mail]:2469:13
> Sync.Status	DEBUG	Status for engine extension-storage: error.engine.reason.unknown_fail
> Sync.Status	DEBUG	Status.service: success.status_ok => error.sync.failed_partial
> Sync.ErrorHandler	DEBUG	extension-storage failed: Error: HTTP 507 Insufficient Storage: Resource access is forbidden for this user (Maximum bytes per object exceeded (17319 > 16384 Bytes.)(resource://services-common/kinto-http-client.js:2341:5) JS Stack trace: [e-mail]:2341:5
> [e-mail]:2469:13

I can provide the raw file if needed (I don't know if there's sensitive data in there)

Comment 1

[Ethan Glasser-Camp (:glasserc)]

It looks like the side-view extension exceeds the `QUOTA_BYTES_PER_ITEM` limit, which is 8k in Chrome but is more for us because we store a base64'd encrypted version.

Comment 2

[David Durst [:ddurst]]

NI Luca to see if he can find a cause so we can triage priority.

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

It looks like side-view is using the storage.sync API only in two places:

- to store the recent visited tabs: https://github.com/mozilla/side-view/blob/e78a7866fa50a942d430ea56e555c941e53ecbbd/addon/background.js#L257, 
  which is already capped to a maximum number of 5 tabs (https://github.com/mozilla/side-view/blob/e78a7866fa50a942d430ea56e555c941e53ecbbd/addon/background.js#L23)

- to store which hosts should be in desktop mode when opened in the sidebar: https://github.com/mozilla/side-view/blob/e78a7866fa50a942d430ea56e555c941e53ecbbd/addon/background.js#L235

This last one item is not sliced and so I guess that it would be the one that could more easily trigger the issue that Ethan described in comment 1.

I filed an issue in the side-view repo (https://github.com/mozilla/side-view/issues/328), to make them aware of this syncing issue and what may be triggering. 

On the Firefox side, at a first glance it seems that the extension may not receive an error when the client sync request fails because the server reports the insufficient storage error.

I'm wondering if on Chrome is reporting to the extension an error when the storage.sync.set is called with an item that exceeds the quota limit,
given that we are already getting the size of the items for the telemetry (https://searchfox.org/mozilla-central/rev/a41fd8cb947266ea2e3f463fc6e31c88bfab9d41/toolkit/components/extensions/ExtensionStorageSync.jsm#1122) it seems that we could check if the item exceeds the quota and reject the API call.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

I'm reopening this bug and leave it as a bug depending from Bug 1311516 (instead of being resolved as a dupe).

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

Client-side quota has been introduced along with the new rust-based storage.sync implementation.

Comment 10

[Mathew Hodson]

Fixed by bug 1637166 and enable in bug 1634615.