Unable to reproduce the issue on reported chrome version 64.0.3282.186 using Ubuntu 14.04 with the below mentioned steps.
1. Launched Chrome
2. Enabled the Developer mode in chrome://extensions
3. Added the extension from .zip file provided in comment#0
4. Gave the input values as 1000, 7350, 7500 and 8000
We observed the storage events got registered with out any issues. Attaching the screen cast of the same.

@jainabhishek: Could you please have a look at the screen cast an let us know if we have missed anything in the process of reproducing the issue.

Deleted: 818208.mp4 1.5 MB

	818208.mp4 1.5 MB View Download

/cc Devlin for storage limit + sync interaction.

My guess is that this is just hitting the maximum quota for an item stored in sync, which is 8k (documented as QUOTA_BYTES_PER_ITEM at [1]).  While the string itself is fewer than 8k, my guess is that the serialization of it reaches that limit, and this fails.  That said, I'm surprised that this happens for 7350 length - the jsonification + key shouldn't account for *that* much space.  It also seems like it wasn't able to reproduce in #1.

treib@, any thoughts from the sync side?

[1] https://developer.chrome.com/extensions/storage#type-StorageArea

Yeah, IIRC, the max size for a single Sync item is 8K *including Sync metadata*, so the actual usable size is a bit less than that. I don't know exactly how much space the Sync metadata will take, but a few hundred bytes sounds plausible.

Not sure what can reasonably be done about this - maybe just update the documentation for QUOTA_BYTES_PER_ITEM [1]?

[1] https://developer.chrome.com/extensions/storage#property-sync

wow - that's a lot of metadata (if e.g., all I want to store is a string).  I'd be curious what all we need to store there per-item, but that's a separate discussion.

Is there a) any way to determine the size of the metadata and b) any guarantee of it remaining constant?  Otherwise, updating the documentation is a little less helpful (e.g., "The limit is 8k, minus a magic number that can change").  It'd be really nice if developers can just use the property exposed to be able to calculate if they will need to batch the data somehow.

Okay, first off two caveats:

1) I don't actually know the amount (#bytes) of metadata we store. It includes things like a server-provided ID, creation timestamp, last change timestamp, and a bunch of other things. You can go to chrome://sync-internals, "Sync Node Browser" tab, and open any node - AFAIK everything apart from "SPECIFICS" is stored as metadata.

2) I was assuming that these storage items map 1:1 to Sync entities, but I don't know if that's actually true.

To your questions:
a) No, AFAIK there's no way to query the metadata size.
b) I'm not aware of any formal guarantee, but it should be very stable.

I realize this isn't very satisfying :(

Adding some other Sync folks in the hope that they'll tell me how wrong I am. :)

The server-side (hard) limit is 10KiB, including (I believe) payload, metadata, and ID. I bookmarked a huge (20K data:) URL which failed to sync. The surrounding metadata, according to chrome://sync-internals, amounted to 2720B, and the entity ID to 168B. 10KiB - (2720B + 168B) = 7352, so we’re in the right ballpark.