We run origin/stable from rP (times three), except for reverting rP71bda66870d8ef832f4d048b11282f9ae0086f05 to prevent this issue from occuring.

In T10326#158479, @chad wrote:

I think I suggested "Project Tags" at one point.

The issue is back, but this time it affects an existing repository, which I was using successfully for a long time. Please reopen.

I think I suggested "Project Tags" at one point.

I think it's probably better, but renaming it causes this in Diffusion:

Understood, I just don't know if it was intentionally not converted (@epriestley made the changes). It's just one line in the code and it'll update on all the Property Lists. Do you feel Tags is better everywhere over Projects. That is, are your users less confused about the product?

I see. It's also still "Projects" in Maniphest - I assumed the intention was to rename it everywhere where "projects" carries similarities to "tags" in a broad sense, since a common misconception about our users is for example that repositories or tasks "belong" to one project alone. I already explained that this is not the case to most of them several times and also wrote it in our internal documentation, but it still comes up, especially for people new to Phabricator. Thus I assumed that this is also a common misunderstanding in other groups and the renaming effort is targetted at this exact problem.

But maybe @epriestley did want this field changed also?

I think "Tags" in the Property List context is incorrect, since other data about the Project (like the Workboard its on) is also provided.

Your proposal seems even better than mine as it does not depend on the manifest ordering. I will be happy to see the fix showing up in the repository.

Reporting the same behaviour. Fetch hangs on our biggest repo.
Reverting the gzip commit fixes the problem.

Got the same problem with only one of my repos (~ 50MB, largest one).
Reverting the commit mentioned by @dtf fixed the problem.

Will do

In cases where we can find the root cause and provide guidance or raise a setup issue, we do. If you do get more information on this, let us know.

I agree, it's fishing. I've done all I can do and gave up. I converted to using SSH instead, which is probably better anyway.

In T10296#157687, @chad wrote:

You're welcome to spin up a test instance on http://phacility.com/ and reproduce there (our platform - your client).

You're welcome to spin up a test instance on http://phacility.com/ and reproduce there (our platform - your client).

In T10296#157683, @chad wrote:

You'll want to start debugging your curl / ssl certificates (I don't think this is a Phabricator issue).

You'll want to start debugging your curl / ssl certificates (I don't think this is a Phabricator issue).

I installed compiled and installed git from sources on the server, v2.7.1 and that did not solve the problem:

This has been live for a few weeks without any issues, and I generally expect it to have nearly zero impact on reasonable workflows, so I'm going to assume the best and close this out.

Same thing, just one repo out of many (biggest one, only 400 MB, though).
Reverting the {71bda66870d8ef832f4d048b11282f9ae0086f05} helps.

I'm experiencing exactly same problem while accessing one of my repos via HTTP.

We are currently experiencing this problem on one of our repositories, but not the other 50 or so.

It ok no feel bad

Thanks for the report @perezd and sorry for my bad testing!

I feel dumb because in my testing I set the field to literal null and not null.

and also the culprit! hoo hoo hoo!!

@epriestley is the hero.

mine looks identical to yours (app settings)

PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:34:46)
Ubuntu LTS

(also maybe helpful, what PHP/OS you are running)

/applications/view/PhabricatorFilesApplication/

Can you look and see what your limit is set to?

These files were well under 1MB FWIW.

b51a859636ac was recent, so maybe it did break something.

It's anything over 1MB.

I haven't tried to reproduce this, but the error about "store large files" seems out-of-place if the files are small.

I had never setup anything for file storage in the past. It was never configured.
I've restarted php/apache many times, including immediately after I updated it as the documentation states to do.

If you just updated Phabricator, how long has it been and did you restart PHP/Apache?

set that field to null, and you can repro it.

set that field to null, and you can repro it. I did not get this error prior, and I should not be getting an "upload" error as I try to simply view a source file in my git repo via diffusion.

https://secure.phabricator.com/book/phabricator/article/configuring_file_storage/ explains file storage in Phabricator.

Maybe I'm missing something obvious, You say if you set the local-disk path the error goes away. So what is the bug you are reporting, specifically, and how can we reproduce it.

Yes?

Is this a bug report?

I'm out of ideas and can't reproduce this problem, then, so we can't move forward (see Contributing Bug Reports). Here's, e.g., this working fine for me against this server:

I updated to get rP9d125b45 and there is no change. Cloning a repo using http still hangs. I then reverted the change in rP8269fd6 and that did not fix the problem either.

@cspeckmim I just fixed that, unfortunately, it doesn't help. Here is a complete debug output when trying to push:

Thanks for the update of the documentation and the explanation. Perfectly fine for me.

@andyboeh - I think there might be an issue with some of the fixes I was looking at. When removing the bundle2 capability from reply, the message preceding the capabilities output is a length of the following line, usually something like

242
capabilities: a, b, c, d, bundle2=http%%%%%...

By just removing bundle2 it causes the preceding number to be off, which is what the client uses for parsing the stream. I haven't gotten back to looking at this but I think that's the issue you're seeing.

I'm unable to reproduce this against this host or hosts in the Phacility cluster.

D15173 updates the documentation.

I am on Mercurial 3.6 on both, the server and the client, and just tried what @cspeckmim suggested: Removing bundle2 from the capabilities in reply to the hello command. Now my client gets one step further, but still fails to push most of the time with remote: abort: stream ended unexpectedly (got 0 bytes, expected 4)

Tested with rP9d125b459ea8, and it's working properly: thanks for the quick fix!

ip2long can also return negative values (see rP30473549).

Ok, thanks, note that this problem is probably the same as this one: T7260
But it seems to be easily reproducible with linux repo.

Nevermind me, Google suggests IPv6 a pain in PHP

FWIW, PHP 7 is not yet supported.

I'm using PHP 7.0.2 with nginx 1.8.1, and running Phabricator at HEAD:

Not sure if lisk should interpret "false" as "null" in this case?

I cloned Linux and examined the commit, but couldn't immediately see anything wrong with it. I'll do the full import when I have a chance.

I merged these to stable and upgraded web001 to fix the immediate issue. The utf8 fix technically needs to go to the repo hosts, but we don't need it there immediately since it only aided in identifying and debugging the gzip issue.

Alright, I made some progress on this.

@rftfaria Did you just disable selinux... or did you work through it?

Slightly more useful:

Logging for this is now in production, but the initial data is totally useless:

Thanks for this, just got caught by it myself.

(This is the 3rd time this came up in IRC). Looks like people are trying to keep phabricator-ssh-hook.sh close to the phabricator code.