7

I have a copy a source code which I added to my commit of Azure DevOps Git Repo and trying to push it to cloud. It keeps failing with the following error

RPC failed; HTTP 503 curl 22 The requested URL returned error: 503

I tried setting git config --global http.postBuffer 157286400 nothing is helping

$ git push --set-upstream origin dummy
Enumerating objects: 1653, done.
Counting objects: 100% (1653/1653), done.
Delta compression using up to 8 threads
Compressing objects: 100% (847/847), done.
Writing objects: 100% (1651/1651), 143.86 MiB | 292.86 MiB/s, done.
Total 1651 (delta 765), reused 1648 (delta 764)
error: RPC failed; HTTP 503 curl 22 The requested URL returned error: 503
fatal: the remote end hung up unexpectedly
fatal: the remote end hung up unexpectedly
Everything up-to-date

Tried all options in this asnwer: https://stackoverflow.com/a/50470075/942855 but no use

How do I overcome this challenge and push my code to Azure Git?

HaBo
  • 13,999
  • 36
  • 114
  • 206
  • Possible duplicate of [503 error pushing to remote](https://stackoverflow.com/questions/37488733/503-error-pushing-to-remote) – alex Sep 18 '19 at 14:28
  • tried that answer https://stackoverflow.com/a/50470075/942855 , but no use – HaBo Sep 18 '19 at 14:30
  • Try SSH: https://stackoverflow.com/questions/15240815/git-fatal-the-remote-end-hung-up-unexpectedly – alex Sep 18 '19 at 14:31
  • 1
    Have you tried ```git config --global lfs.activitytimeout 60``` and ```git config --global http.version HTTP/1.1```? – Mohsenne Feb 27 '20 at 16:25
  • No I did not. I ended up giving away some history. – HaBo Feb 28 '20 at 06:44

3 Answers3

4

I ran into 503 errors on git push on LFS-tracked files (of size ~250 MB) on Azure Repos Git recently:

< HTTP/2.0 503 Service Unavailable
< Content-Length: 14084
< Cache-Control: no-store
< Content-Type: text/html
< Date: Wed, 18 May 2022 10:20:44 GMT
< X-Azure-Externalerror: 0x80072efe,OriginConnectionAborted
< X-Msedge-Ref: Ref A: ***************** Ref B: ***************** Ref C: 2022-05-18T10:18:41Z
< 
03:20:49.327114 trace git-lfs: xfer: adapter "basic" worker 0 finished job for "*****************"
03:20:49.327114 trace git-lfs: tq: retrying object *****************: Fatal error: Server error &{%!!(string=https) %!!(string=) %!!(*url.Userinfo=<nil>) %!!(string=**project**.visualstudio.com) %!!(string=/**project**/_git/**repo**/info/lfs/objects/*****************) %!!(string=) %!!(bool=false) %!!(string=) %!!(string=) %!!(string=)}s(MISSING) from HTTP 503

Reverting to HTTP/1.1 resolved the issue; the LFS upload of my 250 MB files succeeded. I suspect it was an HTTP/2.0 issue that was causing problems with LFS uploads in my case.

To set HTTP/1.1, run:

pwsh> git config http.version HTTP/1.1
Sachin Joseph
  • 18,928
  • 4
  • 42
  • 62
  • 1
    This should be the accepted solution. It's 2023, Azure DevOps claims to "fully support git-lfs" and yet not even HTTP/2 is working… – Henning Aug 30 '23 at 01:52
2

The HTTP error 503 means that the service is unavailable. From RFC 7231:

The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.

Like all 5xx errors, this is a server-side problem, and nothing you do is going to fix it. If the problem were something you were doing, then you'd get a 400-series error, which are client errors.

It's possible that if you're using a proxy, a third-party firewall or antivirus tool, or some sort of other MITM device, then this is the cause of the problem; if so, you should try without that software (by completely uninstalling it and restarting), trying from a network without that proxy or MITM device, or contacting the person responsible for the system.

If you're not using any such software or system, you should contact the Azure DevOps support folks and ask them about the problem. They would be the only people who would be able to fix it.

Setting http.postBuffer should have no effect unless the HTTP server has a serious defect. The Git FAQ entry explains what it does and why it should not be set unless you really need it.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • I agree, there is no real solution to my problem I think it might be server-side related as you said – rakwaht Oct 21 '20 at 07:45
0

If it doesn't work for the maximum value for http.postBuffer, I'd recommend to keep it a bit longer. Let's now split the source code into separate git pushes. You can add different components of the source code in different commits.

git add <comp-1> && git commit -m "Added part 1" && git push"
git add <comp-2> && git commit -m "Added part 2" && git push"

And once that worked, it's a good idea to reset the postBuffer to the default

git config --global --unset http.postBuffer

to avoid inefficient performance penalties.

Casper Dijkstra
  • 1,615
  • 10
  • 37