I wonder if this OOM error can also be hit in other workflow though, given that it seems to occur in PhabricatorFileStorageEngine::getRawFileDataIterator.

Yep, agreed that the re-targeted proposal is a better solution... I had just assumed that this was a documentation oversight.

In T12950#230520, @chad wrote:

Why did they need regenerating in the first place?

I'm seeing these errors failing regularly:

I've got a reproduction case for this now: https://secure.phabricator.com/differential/diff/44008/

Ok thanks

See PHI18 for discussion

@hach-que, did you end up implementing a solution for this?

Good catch

I am also seeing this error and am trying to work on a fix.

minor

Another correction, Puppet doesn't //need/ a dedicated server. You can run Puppet in a standalone (agent) mode, if you are willing to somehow get your Puppet manifests onto each host that you wish to provision.

In T12856#227621, @amckinley wrote:

Terraform Review
Pros:

• Written in Python, which everyone knows is superior to Ruby in every way

FWIW, I am actively working on a Puppet module for Phabricator, see https://forge.puppet.com/joshuaspence/phabricator.

AWS doesn't have a single device which can both listen for TCP on 22 (only ELB) and terminate SSL for websockets (only ALB).

Ah sorry, I should've made that clear. Yes, I am able to reproduce the issue on our installation.

In T12907#228951, @chad wrote:

This is not a test install.

Is there a way to exclude users/projects from a query? A user on our install has asked for a way to search for Differential revisions with Project X as a reviewer where the author is not a member of Project X.

I think that something is broken here... when I click "Show Raw File (Right)" I get an empty (zero-byte) response.

In T1026#224714, @epriestley wrote:

I currently expect to revert this change and decline to implement the feature because it makes using Differential on a phone more difficult for left-handed users

Thanks for the very detailed response.

Yep, that's a better solution. In the mean time, we just updated all of our .arcconfig files.

@epriestley, if you had any thoughts on this it would be appreciated as this issue is heavily affecting our users. There is a workaround (update our .arcconfig files to point to the new domain), but we have a lot of repositories...

For git, is that because discovery only happens on the Almanac device on which the repository is bound to or is it because there is some sort of global lock taken for repository updates? I'm curious to learn more bout how this works.

Thanks.

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.

This was a misconfiguration on my part and I wasn't properly forwarding the query string from nginx to PHP.

Possibly related, I'm having issues with Almanac too. I created an Almanac device, but clicking on "Add Interface" takes me to /almanac/interface/edit/?deviceID=2 which shows a 404.

In T12547#219587, @epriestley wrote:

Was this on a test install on localhost? I can only reproduce this if the remote address is part of cluster.addresses.

Ah this probably explains what I have observed on our installation too.

As in... If users hot this error from non-CLI mode then they probably need to change the file permissions or add their web user to a group. If users hit this from the CLI then they need sudo

We could tailor the message differently based on CLI/FPM?

In D17917#216915, @epriestley wrote:

Do you have some text which you think would be more clear?

It may have permissions which are too restrictive.

Sure.

Use Filesystem class

In D17917#216892, @epriestley wrote:

I'm happy to bring a version of this upstream, but it should probably Filesystem::readFile(...), phutil_json_decode(), and distinguish between "can not read" and "read it fine, but your JSON is junk".

A vaguely related question... how is the /status/ endpoint meant to work behind an ELB? AWS ELB's don't pass a Host header to the healthcheck endpoint, so by default it just returns a 500. I worked around this by using some nginx voodoo to rewrite the Host header if the User-Agent header matches ^ELB-HealthChecker/\d+\.\d+$, but this is less-than-ideal.

I think the author is essentially asking for an easy way to map inline comments to the diff that they were originally made upon.

In T5155#223416, @epriestley wrote:

As a general note here, we've been vulnerable to credential theft from the local service throughout this discussion, and still are until T12701 resolves: attackers can create a Harbormaster build plan which sends requests to 169.254.169.254, then read credentials from the output of the "failed build".

In T12689#223076, @epriestley wrote:

(But what if you meant "I'm not going to review this but still want to keep an eye on it" instead of "I'm not going to review this and don't care about it at all"?)

rPbcd87e0e3f3756970d26d5e9c4a60e4be73ef6a6
rARC3c4735795a2963c5ddff6dceaf60122d01ca3dc0
rPHUa900d7b63e954e221efe140f0f33d3d701524aae

Another possibility here would to be introduce ArcanistUnitTestResult::RESULT_UNSTABLE.

LGTM. @epriestley, it would be greatly appreciated if this could be accepted upstream. We have a large number of XHPAST linter rules (I think ~200) and we want to write integration tests to ensure that they play nicely together.

I'm just going to trust that you will fix this after D17819 lands.

I think this needs to be updated? It fails for me locally.