1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #3776 resolved

abort: stream ended unexpectedly (got 47997 bytes, expected 55071)

Igor Dykman
created an issue

After a crush during push process, all our developers getting following errors when trying to pull incoming changes : abort: stream ended unexpectedly (got 47997 bytes, expected 55071) (Please see attached log file for more information) I believe it should be fixed on bitbucket side. Please help. Thanks, -Igor.

Comments (9)

  1. Nicolas Venegas

    Hi Igor

    Running hg verify on your repository on our serves shows that it is corrupt (I've redacted the filenames below since your repository is private):

    42153 files, 3355 changesets, 62315 total revisions                                                                                         
    321 integrity errors encountered!
    (first damaged changeset appears to be 3350)

    What I can do is restore the repository to the parent revision of 3350 which should put the repository back in a useable state.

    Let me know if I should go ahead with this. I'd also recommend that you run hg verify on your local copies of that repository.



  2. Igor Dykman reporter
    • changed status to open

    Thanks for the quick reply! Yes, please go ahead and restore the repo. Is there any way we can avoid / fix problems like this in future? Thanks, -Igor.

  3. Nicolas Venegas


    Just as I was going to restore the repository, it now appears to not have any errors (unless someone else on the team fixed it behind my back):

    $ hg verify
    checking changesets
    checking manifests
    crosschecking files in changesets and manifests                                                                                             
    checking files
    42168 files, 3374 changesets, 62502 total revisions

    Can you try using it again and let me know if you still see the stream ended errors or any other kind of error?



  4. Igor Dykman reporter

    yes, it works now. But I'd like to have a better understanding of: 1. how it was fixed 2. what should we do to avoid such problems in the future. It looks like a bug on hg side, no crush on client should lead to repo corruption 3. If we hit the same problem in future, is it possible to resolve it on our end, or we have to rely on bitbucket customer support?

  5. Nicolas Venegas


    I think the most likely ways a repository may get corrupted are:

    1. an interrupted transfer to bitbucket.org,
    2. pushing a repository that has become corrupt locally, and
    3. an operation on our servers initiated from the web site (e.g., accepting and merging a pullrequest) that takes too long and is killed.

    It's hard to say how to avoid this problem from occurring in the future: running hg verify locally often isn't really a solution (and would be cumbersome).

    There is an experimental setting for mercurial that we could try on our end to verify pushes and reject corrupt ones, but there is a performance penalty for this and this setting may not be supported in future versions of mercurial.

    If you run into this problem again, at the moment, emailing support@bitbucket.org is the quickest way to get someone on the team to resolve it. Ideally, we'd add some diagnostics to the repository admin section so that our users can check if their repository has become corrupt and possibly offer a way to remedy it from the web site.



  6. Log in to comment