-
Notifications
You must be signed in to change notification settings - Fork 349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync Containers with Temporary Account Containers #1675
Comments
I have the same problem and it get so serious that I am unable to synchronize anything at all due to the huge number of temporary containers synchronized
I have also tried to manually delete the temp containers from EDIT: Obviously the error also tells that now the main problem is how to delete the remote list of containers, since it appears that once you exceed the quota you are unable not only to synchronize, but also to delete stuff. |
Also going to agree. Container sync is unusable with temp container usage. I have at least hundreds of synced tmp*, and dozens of the same tmp# value. It's not possible to remove them at this point, and the only way to fix it is to completely delete all my sync data for the entire browser. PLEASE add wildcard sync exclusions. |
Same here. Hundreds of containers. Impossible to remove, they keep coming back from sync. I have not found out any workaround. |
I had this issue recently too but with a worse side-effect. With sync "Add-ons" options enabled in Preferences I kept getting similar errors:
While erroring out Firefox kept writing these error logs to the profile directory: After each error Firefox tried to sync the profile again instantly (or few seconds delay). And that'd be fine, except it kept happening non-stop and silently, no error notification whatsoever. Problem: Investigation: The constant I/O caused by Firefox hurt the whole system performance and kept crashing Firefox itself. (I've sent more than 10 crash reports recently with the built-in system.) The constant I/O problem was caused by Firefox writing sync errors logs with The sync errors were also constant as a new sync attempt happened after each failure. The sync errors happened while having Expected results:
Observed results:
Workaround:
Usage notes: I use both Multi-Account Containers and Temporary Containers add-ons. I never really pay attention to sync details and just expected it to work silently. As a browser (and add-ons) I don't expect it to be required to manually check the presence of error logs to identify non-recoverable issues of a set-and-forget feature. System:
|
I'm seeing the error above even without temporary containers, and it has broken local storage in my profile. I've reported the issue upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1624586. |
Just checked my weave directory and... what the hell, ~1000 files in 9 days and 2 GiB of logs! |
Found these log files as well here. I had opened #1699 earlier, but I'll close it in favor of this one. |
Hmm. Disabling sync in the extension also doesn't seem to avoid the error. |
In the meantime, I've added the log directory to my backup's exclusion (my directory was ~16GB before nuking it). I'll note that it doesn't seem like anything else is not being synced properly at least, so it's not completely useless. But a way to poke into what is being synced and manually delete whatever is taking up too much space would be great. |
I too have this issue. For some reason the number of temporary containers grew to a very large number without me noticing it and now I get sync error on every sync. My logs took up 9GB. Doesn't help to turn off container syncing, I still get the sync error. |
Quick fix/what helps Problem still persists but it doesnt the break my syncing completly |
I don't think this is just related to temporary account containers. I do not have that extension installed, yet enabling sync exceeds the per-extension sync quota for me. Specifically, I end up with entries in my sync log like:
This makes me think that either too much stuff is being synced, or multi-account container configs are large enough that the 200kB limit is too small. |
As a workaround for now, is there a way to remove all remotely held sync data for Firefox. We can then start over and disable the MAC syncing until this gets resolved? Right now, I cannot use any syncing and firefox generates around 12GB of error logs every other day. I would at least like a way to clear out the remote storage (perhaps taking the current browser instance as the new source of truth and syncing from there). I should add, I mean remove just the addon syncing, I dont want to lose everything else in my firefox account. |
If you're getting the "Insufficient Storage" error, a workaround that might help for now is disabling MAC sync and clearing its sync storage like so:
await browser.storage.sync.clear();
console.log("done");
|
Thanks for this, but sadly it doesn't work. After following the above, i get Interestingly, it seems there are two other add-ons failing in the logs. I don't know if that's because those add-ons also cause issues, or if its just because the store is full, so all syncing add-ons will fail. I guess I could play with this a little, by creating a fresh browser instance in a container and seeing if the sync storage really was wiped or not. I dont have time for this currently, but will take alook later in next week. Thanks again. |
The |
I do get the console "done" response, so it seems to be working. I do not get any errors when the snippet executes, but there are a lot of other, unrelated, errors being generated when I leave that screen open from other extensions. |
@stoically I can confirm that running
Sync logs before
Sync logs after
Everything done with container sync turned off with FF 75.0 and a fresh profile sync'ing to the account with the issue. |
I found this issue from awhile ago mozilla/notes#791 (comment) . Is it possible once we hit the limit (trigger the 507) we are unable to recover space from remote objects on the server? At this point I think I've confirmed locally I don't have that many container sync objects. |
It seems that the log deluge no longer occurs, though I'm unsure if it is a Firefox, add-on, or sync server change that fixed it. I am seeing noticeable stalls when syncing now because it is trying to sync 100s of temporary containers down. I try to delete them locally, but they sync back up from the server again. Can we please have an option for masking out containers of a given name from syncing? |
Is there any way to recover a Firefox account from the "507 Insufficient Storage" issue? I still can't use MAC with sync ever since it got flooded by temporary containers. Enabling sync pulls back in around 4000 temporary containers to my local Firefox from the sync server. Deleting them locally (using stoically/temporary-containers#371 (comment)) again doesn't get synced with the server (because of 507 error) I see the similar Notes sync issue mentioned above was fixed in mozilla/notes#824. Maybe something similar can be applied to MAC as well? |
I've been trying to debug this To do requests to the sync server directly I used the following in the browser console:
kintoHttp methods are listed here. There's one bucket. You can get it with
The bucket has several collections named
In my case, one of the collections had around 300 records and others were empty:
I assumed the collection with 300 records was associated with the MAC extension. Deleting the collection for it results in the 507 error turning into:
Re-making an empty collection with the same name results in the
This is as far as I got. I don't know why MAC still tries to store an excessive amount of data on the sync server even with a) local sync storage cleared out b) reasonable number of containers defined and c) remote data cleared manually. At least it seems that the source of the problem is not the server refusing to recover space after hitting the 507 error. |
I can testify from some experiment I've done for the last 3 days about deleting, The sync log are not cleared about it. But the add-on temporary containers disable the ability to sync apparently. So is it wanted like that by the add-on? By the sync process of Firefox itself? Something else? |
I can also confirm this issue still persists for me with the latest 7.4.0 update. Was the |
Hello, The issue still not fixed since many year. And I see also that the PR was revered (8e7d9f7). So @dannycolin why did you reverded this change ? And is it possible to have one day a fix about this ? |
It was reverted via #2450 in case that answers your question. |
Thanks for the answer. I understand more why this revert. So can you open again this issue as it still not be resolved now. |
I cannot reopen; I'm only a user like you :) . |
Maybe @dannycolin can open it again ? |
I can reopen it. However, the author of Temporary Containers passed away last year. Also as an unpaid contributor, I do not have any free time to work or review a patch for this bug. Finally, I can't push a new release on addons.mozilla.org because I don't have the access. So, we'd need someone at Mozilla for that. |
As there is likely no complex solution in the short term, the ability to simply wipe the extension and start over seems reasonable and presumably not too complicated to code. |
Information
Temporary Containers v1.8
Actual behavior and Expected behavior
It is syncing all Container Labels and works fine
Problem
It is also syncing all Containers from the Temporary Account Containers Addon.
Temporary Account Container is deleting the tmp containers after the Tab is closed for 2 minutes. So it is often synced to the cloud.
So i am getting on all other Firefox instances the "tmp**" labels from my other clients.
It would be good if it is possible for example to disable syncing all containers with Syntax "tmp**"
Feature Request
Allow to disable/ignore syncing for cointainers with special characters or syntax
Steps to reproduce
The text was updated successfully, but these errors were encountered: