723638 - Mercurial 2.1 returns 1 if nothing was pulled, in which case client.py doesn't succeed

Status: RESOLVED WONTFIX

(MailNews Core :: Build Config, defect)

Description

[Frederic Bezies]

Very recent problem. For a few hours, when I type python2 client.py checkout --verbose, I got this message :

The exception was:
subprocess.CalledProcessError: Command '['/usr/bin/hg', 'pull', '-R', './.']' returned non-zero exit status 1

Traceback (most recent call last):
  File "client.py", line 609, in <module>
    do_hg_pull('.', options.comm_repo, options.hg, options.comm_rev)
  File "client.py", line 330, in do_hg_pull
    check_call_noisy(cmd, retryMax=options.retries)
  File "client.py", line 158, in check_call_noisy
    raise Exception("Command '%s' failed %d time(s). Giving up." % (cmd, retryMax + 1))
Exception: Command '['/usr/bin/hg', 'pull', '-R', './.']' failed 2 time(s). Giving up.

Of course, client.py python script was working perfectly a few hours ago.

Comment 1

[Justin Wood (:Callek)]

Does running:

hg pull -R ./.

work for you when run manually? it sounds like you're having problems pulling from hg itself, but before we stuff this over to ServerOps I want to be sure.

Comment 2

[Frederic Bezies]

Looks like it work.

[fred@fredo-arch src]$ hg pull -R ./.
pulling from http://hg.mozilla.org/comm-central/
searching for changes
aucun changement trouvé

I'm using a french translated mercurial, last sentence meaning : no changes found.

Comment 3

[Justin Wood (:Callek)]

can you try client.py again then?

Comment 4

[Philipp Kewisch [:Fallen][☁️📆]]

Good this just came up, I had the same issue on the calendar builder. I might know whats happening.  Try this:

hg pull -R ./.
echo $? 

You'll see that since there are no changes, hg returns exit code 1, which client.py thinks is an error.

Comment 5

[Philipp Kewisch [:Fallen][☁️📆]]

Happens for me with Mercurial 1.9.1 on windows

Comment 6

[Philipp Kewisch [:Fallen][☁️📆]]

Actually, its Mercurial 2.1!

Comment 7

[Frederic Bezies]

(In reply to Philipp Kewisch [:Fallen] from comment #4)
> Good this just came up, I had the same issue on the calendar builder. I
> might know whats happening.  Try this:
> 
> hg pull -R ./.
> echo $? 
> 
> You'll see that since there are no changes, hg returns exit code 1, which
> client.py thinks is an error.

You got it. A bug in client.py ?

Comment 8

[Justin Wood (:Callek)]

(In reply to Frederic Bezies from comment #7)
> (In reply to Philipp Kewisch [:Fallen] from comment #4)
> > Good this just came up, I had the same issue on the calendar builder. I
> > might know whats happening.  Try this:
> > 
> > hg pull -R ./.
> > echo $? 
> > 
> > You'll see that since there are no changes, hg returns exit code 1, which
> > client.py thinks is an error.
> 
> You got it. A bug in client.py ?

Actually, imo this is a bug in hg, however it was intentionally changed to do this afaict.

HG is returning what is really an error code (`1`) when it has no changes. They apparently have had this behavior for a while with hg incoming which was determined as intended, so I suspect this is to match  that behavior.

It means that we will be fixing client.py to work around this :/ No ETA yet, but we will plan on getting it into all current repos when fixed.

Comment 9

[Philipp Kewisch [:Fallen][☁️📆]]

Temporary workaround: Install Mercurial 2.0.2, where it still returns 0.

Comment 10

[Frederic Bezies]

(In reply to Philipp Kewisch [:Fallen] from comment #9)
> Temporary workaround: Install Mercurial 2.0.2, where it still returns 0.

Downgraded mercurial. Hope this problem with mercurial get fixed soon :D

Comment 11

[Justin Wood (:Callek)]

(In reply to Frederic Bezies from comment #10)
> (In reply to Philipp Kewisch [:Fallen] from comment #9)
> > Temporary workaround: Install Mercurial 2.0.2, where it still returns 0.
> 
> Downgraded mercurial. Hope this problem with mercurial get fixed soon :D

From the looks of it, it was intentional on their side, so we'll need to fix it in our script here.

Sad, but true.

Comment 12

[Nomis101]

Yesterday I've updated to Mercurial 2.1 via Macports and now I'm also seeing this error. And I can't downgrade Mercurial, because there is only version 2.1 available on MacPorts now.
https://bugzilla.mozilla.org/show_bug.cgi?id=725362#c5

This would not matter for me if there were only this error, but it also doesn't update my tree. It doesn't pull the latest changes.

Comment 13

[Justin Wood (:Callek)]

(In reply to Nomis101 from comment #12)
> Yesterday I've updated to Mercurial 2.1 via Macports and now I'm also seeing
> this error. And I can't downgrade Mercurial, because there is only version
> 2.1 available on MacPorts now.
> https://bugzilla.mozilla.org/show_bug.cgi?id=725362#c5
> 
> This would not matter for me if there were only this error, but it also
> doesn't update my tree. It doesn't pull the latest changes.

Workaround is to manually pull, alternative is for me to say "patches accepted".

Sadly I just don't have time this week to do this patch, but would review any patch here asap.

Comment 14

[Nomis101]

(In reply to Justin Wood (:Callek) from comment #13)
> Workaround is to manually pull, alternative is for me to say "patches
> accepted".
> 
> Sadly I just don't have time this week to do this patch, but would review
> any patch here asap.

What is needed here to fix this?

Comment 15

[Justin Wood (:Callek)]

(In reply to Nomis101 from comment #14)
> (In reply to Justin Wood (:Callek) from comment #13)
> > Workaround is to manually pull, alternative is for me to say "patches
> > accepted".
> > 
> > Sadly I just don't have time this week to do this patch, but would review
> > any patch here asap.
> 
> What is needed here to fix this?

Roughly Speaking unravel most of the command runs here to check return code and in the "legit" cases treat `1` as ok, and don't exit client.py/abort.

Comment 16

[Nomis101]

OK, I see. I'm willing to play arround with that and, in the best case, fix it and make a patch. But I can't promise anything...

Comment 17

[Robert Kaiser]

Ah, now I realize this is the problem I'm seeing recently on my desktop machine.

Did earlier Mercurial versions return 1 in cases that are legit errors? If yes, we probably need some kind of version detection in client.py to deal with that - if no, it should be easy to take >1 as failure and <=1 as success.
(Bah, a return code other than 0 for a non-failure is violating usual standards of unix-like systems, but I guess hg just doesn't care about that.)

Comment 18

[Robert Kaiser]

I'll set this to WONTFIX, as Mercurial has reverted this in 2.1.1 and that version works well with client.py again.