Series of sync problems using ZFS

I get an error while file syncing to Zotero storage: "Unexpected file registration statues 201... onUploadComplete()". ID 940612104. Two earlier threads on this in the forums have not been solved, it seems, which is why I start a new thread.

I will restart FF and retry in a while. The file sync operation I'm doing is huge (8Gb), and this was at the 71 file or so (less than 1%).
  • After a restart it goes on for another 2% and halts with "Unexpected status code 0 in Zotero.Sync.Storage.Session.ZFS._getFileUploadParameters()". Error ID 864605602 (not very informative it seems).
  • And after another restart I get error ID 536128358, "Invalid response retrieving file upload parameters".
  • Plus error ID 1017891187, "Unexpected file upload status 500 in Zotero.Sync.Storage._onUploadComplete()".
  • I am still continuing to retry, although I'm not sure I can trust the sync process now (will it have skipped files? What about the files that generated an error?). Each time it runs for ten minutes or less and then halts with an error.
  • edited December 10, 2009
    And there I got another "Invalid response retrieving file upload parameters", error ID 1034177998 (includes some previous stuff too since I haven't restarted each time).

    Could some of these be caused by missing attachments? I have an open feature request on that — in short, make it easier for the user to find and fix them.
  • edited December 10, 2009
    Okay, ID 1541515106, another "Invalid response retrieving file upload parameters". That's it for today. I'll stop.
  • We'll need Debug IDs for these sync attempts, not Report IDs.
  • Okay, I can retry tomorrow with debug output on.
  • edited December 14, 2009
    Okay here's one: D676692053 (together with report ID 12366407, if that matters). The error is the same as some of the attempts above.

    And here's another one: D416479238 (with the by now familiar "Unexpected file registration status 201 in Zotero.Sync.Storage._onUploadComplete()").
  • edited December 14, 2009
    The first one is actually just the Amazon S3 backend saying, "We encountered an internal error. Please try again." I suspect it's an intermittent error that you wouldn't get (for the same file, at least) on a subsequent attempt.

    We could have Zotero automatically retry requests when that occurred, but it's safer just to throw a normal error and wait for the next sync attempt, since it's a generic server error that could be either temporary or permanent and, if there actually were a permanent problem, it would be bad for Zotero to simply keep retrying.

    I've updated the message that Zotero displays in that case, however, to say "File upload failed. Please try again."

    Other Report/Debug IDs still welcome.
  • And the second one appears to just be fallout from the first error (which occurred again there as well). We'll see if we can avoid the separate error message.
  • edited December 14, 2009
    And now I'm having one upload queued forever, with an increasing queued waiting time each attempt:

    (3)(+0000357): <?xml version="1.0"?>
    <response timestamp="1260786205.7956" version="6"><queued wait="10000"/></response>


    (3)(+0000000): Upload queued — waiting 10000ms before next check


    Perhaps the upload server is temporarily unavailable, or could it have to do with the funny filename? See D1884294098.

    /edit

    And after a while I get an Empty response from server (D1604660324).
  • It got past that and seems to be working again. I'm a bit concerned to see filenames like Léger - 1971 - Grammaire Dogon—Tomo-kan.pdf pass by in the log as Léger - 1971 - Grammaire Dogon—Tomo-kan.pdf. Is that going alright?
  • Another halt, D46389015 (Invalid response retrieving file upload parameters).
  • I'm a bit concerned to see filenames like Léger - 1971 - Grammaire Dogon—Tomo-kan.pdf pass by in the log as Léger - 1971 - Grammaire Dogon—Tomo-kan.pdf. Is that going alright?
    Yes. Those paths aren't intended to be human-readable, but the files should be saved correctly cross-platform. (They should also appear correctly on zotero.org.)
  • Another halt, D46389015 (Invalid response retrieving file upload parameters).
    Same deal as above—just fallout from an upload error. (You'll see "Unexpected file upload status 500 in Zotero.Sync.Storage._onUploadComplete()" in the debug output when this is the case.) We should be able to eliminate these spurious messages, at least.
  • Okay, I guess D327031252 is another case of fallout then. I do understand that my file sync operation is particularly huge this first time, and that these errors would go away when syncing smaller chunks in the future. But it might be kind of a letdown for new users trying to sync their library for the first time. It's somewhat alarming to see the red exclamation mark everytime. So if you could eliminate these messages, all the better.
  • edited December 14, 2009
    Another one: D1482974734 ("Unexpected file registration status 201 in Zotero.Sync.Storage._onUploadComplete()"). This time it halts on a file in folder GT7Z2A3H which is 75Mb large.

    (3)(+0000001): Upload of attachment GT7Z2A3H cancelled with status code 2152398850

    Which leads me to think that the reason I'm getting so many upload errors is that many of my attachments are quite large (being scans, as opposed to downloaded recent journal articles). Apparently Amazon S3 works better with smaller files?
  • That line doesn't mean it halted on that file.

    Are you behind any sort of proxy server? Are you on a wired or wireless connection? Do you have issues with dropped connections in general?
  • Wired. No, I never have issues with dropped connections. I'm not behind a proxy server either.
  • Anyway, I'm there — all my storage files (I hope) are now online.

    Question: how can I be sure that all of them are indeed synced? And what will happen if I sync the other client now? Will all the 8 Gigabytes be downloaded (probably) or will Zotero be able to see that there are already perfect copies of all attachments on that side?
  • Reviving this thread not really for a sync error but a quirk nonetheless. Again the sync arrow was spinning for a long time over this mysteriously named — upload, with increasing wait times like this:
    (3)(+0000000): Upload queued — waiting 10000ms before next check

    Log D841965352 (sorry, it's a huge log, but this happens way at the end. What is this?
  • That's not the name of a file. It's just a corrupted em dash in the debug line. I'm actually not sure why that's happening, but it's purely cosmetic.

    The message is normal, though. If there are a lot of uploads in progress, uploads may queue for a little while (particularly if they're sizable). We're still optimizing to bring down the longer wait times.
  • Oh I see. I'm happy to hear that.
Sign In or Register to comment.