Export to GitHub

reqpolsync - issue #3

Sync fails when enabling RP Sync on Fx Nightly 30.0a1 x64


Posted on Mar 4, 2014 by Helpful Bear

What steps will reproduce the problem? 1. Firefox Nightly 30.0a1 with sync enabled running a separate profile 2. Installed Request Policy 3. Installed Request Policy Sync 4. Enabled RP Sync

What is the expected output? What do you see instead? I expect to see that RP is now synchronizing my RP data, but as soon as it is enabled, I get the following error message:

"Sync encountered an error while syncing: Unknown error. Sync will automatically retry this action." It is followed by a Sync Now button and every time I press that button, the error message disappears only to reappear almost immediately.

What version of the product are you using? On what operating system? Windows 7 Ultimate x64 RP Sync 0.1.5 RP 0.5.28

Please provide any additional information below. See attached screenshot

Attachments

Comment #1

Posted on Mar 4, 2014 by Happy Bear

We still cannot reproduce the problem.

Could you please enable debug output in RequestPolicy Sync settings, perform all the steps (including an additional sync attempt), and provide us with the Browser Console output (Ctrl-Shift-J, select all, copy)?

Thanks!

Comment #2

Posted on Mar 4, 2014 by Helpful Bear

Here you go.

Attachments

Comment #3

Posted on Mar 5, 2014 by Happy Bear

Hmmm... That's strange: The only errors in this log (Line 2 & 6 in your log) seem to be caused by content security and an add-on named "Mozilla Archive Format" (GUID {7f57cf46-4467-4c2d-adfa-0cba7c507e54}), which seems to have occasional compatibility problems (see https://addons.mozilla.org/en-Us/seamonkey/compatibility/reporter/%7B7f57cf46-4467-4c2d-adfa-0cba7c507e54%7D). But both errors happened before the sync process.

Firefox sync then seems to try to upload all your RequestPolicy entries - and seems to succeed (Line 11-211 in your log) without any problem.

Could you please try to find a Firefox sync log file pertaining to the problem, and paste it here? (Go to 'about:sync-log' in Firefox and check if there are any files named 'error-*.txt' and paste one of those containing RequestPolicy Sync errors).

Comment #4

Posted on Mar 5, 2014 by Helpful Hippo

I'm also having those problems. Here are the last lines of an error log showing that also adblock sync doesn't work when stylish sync fails (I have both RequestPolicySync ans StylishSync installed. Probably a ScriptishSync would be nice btw ;) )

Sync.Collection DEBUG mesg: POST fail 404 https://sync-2-us-east-1.sync.services.mozilla.com/1.5/10085/storage/adblockplus Sync.Collection DEBUG POST fail 404 https://sync-2-us-east-1.sync.services.mozilla.com/1.5/10085/storage/adblockplus Sync.Engine.AdblockPlus DEBUG Uploading records failed: 0 Sync.Status DEBUG Status for engine adblockplus: error.engine.reason.record_upload_fail Sync.Status DEBUG Status.service: success.status_ok => error.sync.failed_partial Sync.ErrorHandler DEBUG adblockplus failed: 0 No traceback available Sync.Engine.StylishSync DEBUG First sync, uploading all items Sync.Engine.StylishSync INFO 15 outgoing items pre-reconciliation Sync.Engine.StylishSync INFO Records: 0 applied, 0 successfully, 0 failed to apply, 0 newly failed to apply, 0 reconciled. Sync.Engine.StylishSync INFO Uploading all of 15 records Sync.Collection DEBUG POST Length: 198579 Sync.Tracker.Clients DEBUG Saving changed IDs to clients Sync.Tracker.Bookmarks DEBUG Saving changed IDs to bookmarks Sync.Tracker.Passwords DEBUG Saving changed IDs to passwords Sync.Collection DEBUG mesg: POST fail 404 https://sync-2-us-east-1.sync.services.mozilla.com/1.5/10085/storage/stylishsync Sync.Collection DEBUG POST fail 404 https://sync-2-us-east-1.sync.services.mozilla.com/1.5/10085/storage/stylishsync Sync.Engine.StylishSync DEBUG Uploading records failed: 0 Sync.Status DEBUG Status for engine stylishsync: error.engine.reason.record_upload_fail Sync.Status DEBUG Status.service: error.sync.failed_partial => error.sync.failed_partial Sync.ErrorHandler DEBUG stylishsync failed: 0 No traceback available Sync.Synchronizer INFO Sync completed at 2014-03-05 18:25:59 after 1.72 secs. Sync.SyncScheduler DEBUG Next sync in 600000 ms. Sync.ErrorHandler DEBUG Some engines did not sync correctly.

Unfortunately no traceback there... I'll search in my other logs from the last week for more info...

Comment #5

Posted on Mar 5, 2014 by Helpful Hippo

Every error log shows the same problem :( Browser console:

POST https://sync-2-us-east-1.sync.services.mozilla.com/1.5/10085/storage/adblockplus [HTTP/1.1 404 Not Found 113ms] POST https://sync-2-us-east-1.sync.services.mozilla.com/1.5/10085/storage/stylishsync [HTTP/1.1 404 Not Found 215ms]

I don't know the new sync protocol very well but it seems that those folders in my sync storage a somehow missing... probably ABP, StylishSync ans RequestPolicySync don't correctly check sync folder existence/creation or my sync storage is bugged or sync API has a bug...

Comment #6

Posted on Mar 5, 2014 by Helpful Bear

OK, I went and found the logs for FX - there are a lot of them all from when I started using sync and then enabled RP Sync.

I've .ZIPped them all up and am attaching them so they may be of some help to you.

Attachments

Comment #7

Posted on Mar 5, 2014 by Helpful Hippo

Yeah, info/collections only returns {"passwords", "addons", "tabs", "clients", "crypto", "meta", "bookmarks", "prefs"} for me, so theres no abp, stylishsync or requestpolicysync collection.

Nevertheless, the 404 return code seems to be wrong, as the specification clearly states: "Non-existent collections do not trigger a 404 Not Found for backwards-compatibility reasons."[1].

Probably thats a serverside bug in the new sync protocol. Altough I don't really understand because 1.1 (accordint to spec) always throws a 404 on non found collections, so why would it be backwards compatible if it would not throw one now in 1.5? This feels horribly wrong, either the spec or the implementation is wrong.

[1] https://docs.services.mozilla.com/storage/apis-1.5.html#http-status-codes

Comment #8

Posted on Mar 6, 2014 by Happy Bear

Thanks for your input!

Am I assuming correctly, that you're using a new Firefox account? Existing accounts, where the collections have been created beforehand, seem to work correctly.

Because it seems, that Firefox Sync creates all its default collections and ignores newly registered engines.

Up to now, you did not have to bother about collection creation on the server side. The sync client API (https://developer.mozilla.org/en-US/docs/Firefox_Sync/JavaScript_Client_API) handled this when registering (or first syncing) additional engines. It doesn't even offer an interface to the server collections.

Both reqpolsync and stylishhsync use this API.

I'll investigate. If necessary I might have to file bug on bugzilla...

Comment #9

Posted on Mar 6, 2014 by Happy Bear

johannespfrang wrote: Probably thats a serverside bug in the new sync protocol. Altough I don't really understand because 1.1 (accordint to spec) always throws a 404 on non found collections, so why would it be backwards compatible if it would not throw one now in 1.5? This feels horribly wrong, either the spec or the implementation is wrong.

It seems, you're absolutely right. And there's already a bug for that: https://bugzilla.mozilla.org/show_bug.cgi?id=963332

We'll probably have to wait, until the fix goes live on Mozilla's servers.

Comment #10

Posted on Mar 6, 2014 by Happy Elephant

The spec is ahead of the version that's deployed, but in any case, that bug shouldn't affect POSTs (for obvious reasons). I've forwarded this on.

Comment #11

Posted on Mar 6, 2014 by Helpful Hippo

FYI this is now being addressed bug 980239: https://bugzilla.mozilla.org/show_bug.cgi?id=980239

Comment #12

Posted on Mar 7, 2014 by Quick Rhino

Just to keep you updated, I believe we've isolated the cause of this to an operational issue in our new sync cluster, it should be resolved shortly.

Comment #13

Posted on Mar 7, 2014 by Happy Bear

Thanks a lot @rfkelly0 for the quick fix! It seems to work now.

I'll close this issue as 'Verified'! Feel free to re-open, if problems re-occur.

Status: Verified

Labels:
Type-Defect Priority-Critical