All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Max Kirillov <max@max630.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Eric Sunshine <sunshine@sunshineco.com>,
	Jeff King <peff@peff.net>,
	Florian Manschwetus <manschwetus@cs-software-gmbh.de>,
	Chris Packham <judge.packham@gmail.com>,
	Konstantin Khomoutov <kostix+git@007spb.ru>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH v8 3/3] http-backend: respect CONTENT_LENGTH for receive-pack
Date: Wed, 25 Jul 2018 20:41:31 +0200	[thread overview]
Message-ID: <CAM0VKjkSMqPy=N3_0HUNxpCFwusrD_XE5j7kMsE4L-79g2t_VA@mail.gmail.com> (raw)
In-Reply-To: <20180725145100.GA1959@jessie.local>

On Wed, Jul 25, 2018 at 4:51 PM Max Kirillov <max@max630.net> wrote:
>
> On Wed, Jul 25, 2018 at 02:14:35PM +0200, SZEDER Gábor wrote:
> >> +    # sometimes there is fatal error buit the result is still 200

> >> +    if grep 'fatal:' act.err
> >> +    then
> >> +            return 1
> >> +    fi
> >
> > I just happened to stumble upon a failure because of 'fatal: the
> > remote end hung up unexpectedly' in the test 'push plain'.
>
> Did it happen once or repeated? It is rather strange, that
> one shoud not fail. Which OS it was?

Only once, so far.  It was one of my OSX build jobs on Travis CI, but
I don't know what OSX version is used.

'act.err' contained this (which will get line-wrapped, I'm afraid):

++handler_type=receive
++shift
++env CONTENT_TYPE=application/x-git-receive-pack-request
QUERY_STRING=/repo.git/git-receive-pack
'PATH_TRANSLATED=/Users/travis/t/trash
dir.t5562/.git/git-receive-pack' GIT_HTTP_EXPORT_ALL=TRUE
REQUEST_METHOD=POST
/Users/travis/build/szeder/git-cooking-topics-for-travis-ci/t/t5562/invoke-with-content-length.pl
push_body git http-backend
<...128 zero bytes...>fatal: the remote end hung up unexpectedly

I couldn't reproduce it on my Linux box.

> There have been doubds that a random incoming signal can
> trigger such a failure.
>
> > What does that "sometimes" in the above comment mean, and how often
> > does such a failure happen?  I see these patches are in 'pu' for over
> > a month now, so based on the number of reflog entries since then it
> > happened once from about 30-35 builds on Travis CI so far.
>
> "sometimes" here means "for some kinds of fatal error
> failure", there is nothing random in it.

> >> +    ! verify_http_result "200 OK"
> >
> > ... this function would return error (because of that 'if grep fatal:
> > ...' statement) without even looking at the status, but the test would
> > still succeed.  Is that really the desired behavior here?
>
> Yes, it is a desired behavior. A failure is expected here,
> and the failure does not show up as non-200 status, as
> described above.

OK, then I misunderstood that comment.

Perhaps a different wording could make it slightly better?  E.g. "In
some of these tests ..." instead of that "sometimes".  Dunno.

  reply	other threads:[~2018-07-25 18:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-02 21:27 [PATCH v7 0/2] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2018-06-02 21:27 ` [PATCH v7 1/2] " Max Kirillov
2018-06-04  3:44   ` Jeff King
2018-06-02 21:27 ` [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack Max Kirillov
2018-06-04  4:31   ` Junio C Hamano
2018-06-04 17:06     ` Max Kirillov
2018-06-05  2:30       ` Ramsay Jones
2018-06-04  4:44   ` Jeff King
2018-06-04 22:18     ` Max Kirillov
2018-06-10 15:06       ` Max Kirillov
2018-06-11  9:18       ` Jeff King
2018-06-11  9:24         ` Jeff King
2018-06-10 15:07     ` Max Kirillov
2018-06-11  8:59       ` Jeff King
2018-06-10 15:05 ` [PATCH v8 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2018-06-10 15:05   ` [PATCH v8 1/3] http-backend: cleanup writing to child process Max Kirillov
2018-06-10 15:05   ` [PATCH v8 2/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2018-06-10 15:05   ` [PATCH v8 3/3] http-backend: respect CONTENT_LENGTH for receive-pack Max Kirillov
2018-07-25 12:14     ` SZEDER Gábor
2018-07-25 14:51       ` Max Kirillov
2018-07-25 18:41         ` SZEDER Gábor [this message]
2018-07-26  4:37           ` Max Kirillov
2018-07-27  3:48   ` [PATCH v9 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2018-07-27  3:48     ` [PATCH v9 1/3] http-backend: cleanup writing to child process Max Kirillov
2018-07-27  3:48     ` [PATCH v9 2/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2018-08-04  6:34       ` Duy Nguyen
2018-08-04 11:28         ` Max Kirillov
2018-08-04 17:20           ` Junio C Hamano
2018-07-27  3:48     ` [PATCH v9 3/3] http-backend: respect CONTENT_LENGTH for receive-pack Max Kirillov
2018-07-27  3:50     ` [PATCH v9 0/3] http-backend: respect CONTENT_LENGTH as specified by rfc3875 Max Kirillov
2018-07-27 17:49       ` Junio C Hamano
2018-07-25 12:02 [PATCH v8 3/3] http-backend: respect CONTENT_LENGTH for receive-pack SZEDER Gábor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM0VKjkSMqPy=N3_0HUNxpCFwusrD_XE5j7kMsE4L-79g2t_VA@mail.gmail.com' \
    --to=szeder.dev@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=judge.packham@gmail.com \
    --cc=kostix+git@007spb.ru \
    --cc=manschwetus@cs-software-gmbh.de \
    --cc=max@max630.net \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.