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.

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

Hmm ok. I think that I'm not usually listed explicitly as a reviewer, which means that Reviewers: #some_project_that_i_am_a_member_of doesn't include me. Would you be in favor of adding a new [Differential was reviewed by] field to Herald?

Actually, I figured it out... The problem was that I had security.require-https set to true but I hadn't yet setup HTTPS so I was only using plain old HTTP.

I tried to reproduce this on a Phacility host, but it doesn't reproduce there because the first user account is setup via OAuth.

When I turn on bucketing, I can't see it actually. Although I do have a lot of diffs, so it could have overheated.

This seems to have fixed the issue. Thanks for the quick fix.

Not sure if this is useful:

Hmm, I got a different error with a 9MB file. But this looks like a problem on our end:

I originally tried a 1GB file and wasn't able to reproduce...

From the server-side error logs:

Okay, I managed to reproduce it with non-sensitive data:

OK weird, I can't reproduce it anymore. Anyway, I'll add the response body from differential.querydiffs here. It shouldn't contain any sensitive information, but I'll restrict the visibility of the file given that it does contain email addresses.

Oh wait, this is the unit tests failing. Nevermind

Can haz badge??? 🍺

I don't believe this is related to E being set in variables_order.

In T12144#208351, @chad wrote:

I'd rather fix the core problem if it's an unclear typeahead.

My understanding is that subprojects are basically just regular projects but with a parent relationship. We didn't want these projects to pollute the projects typeahead because no-one should be creating tasks within these subprojects (given that these subprojects dictate what we are working on). By choosing "milestone" instead of "subproject", it becomes clearer in the project typeahead that the subproject is internal to the parent project. That is, if we made #our_january_goal a subproject then it would show up in the projects typeahead as "Our January Goal" whereas as a milestone it is rendered as "Our Team (Our January Goal)".

In T11085#178406, @epriestley wrote:

You're watching #twitter.

In T10038#150670, @epriestley wrote:

Do you see there being a "Blessed" foo-linter (maybe as a repo on this instance?), or will there be multiple foo-tributes fending themselves in the wilds of github?

This is all still pretty early, but I imagine this instance mostly just collecting packages into a directory for now. The actual source might be on GitHub, but you'd be able to search this instance to find all foo-linter extensions by authors who had bothered to register their packages.

In some cases, we'd likely pull linters out of arc and turn them into Phacility-Published extensions (secure.phabricator.com/phacility/foo-linter) which we'd sign. These would be "blessed", as long as you continue trusting our signing keys.

In some cases, I'd like to "soft-bless" extensions as "safe, but don't come to us for support" with some sort of "Community Badge of Quality" key. For example, you might publish a secure.phabricator.com/cburroughs/foo-linter) which we'd sign in an advisory way which mean "we looked at the code, it seems fine, but we aren't taking bug reports for it". The UI and arc install would show users that someone they trust also trusts this code.

In some cases, untamed wilds, but collected in one place and searchable, with signing and a consistent toolset.

If nothing is blessed, you may have to make a decision like this yourself:

$ arc install foo-lint
Query "foo-lint" matches multiple packages:

  secure.phabricator.com/alice/foo-lint
  secure.phabricator.com/bob/foo-lint

None of these packages or vendors are signed by anything you trust.

Which package do you want to install?

But I think that should be OK. And we can do some level of positive and negative curation (advisory signing on good packages, disabling bad packages)..

You'll also be able to have an internal package directory for your company's stuff, so you can just publish internal things to it and then everyone can use standard tools to manage extensions.

Some day far in the future I could imagine the package directory integrating with other applications (e.g., giving each package its own repositories and tasks, like GitHub) but that's definitely far in the future. I expect most extensions (like linter bindings) to be small so they wouldn't get much benefit (e.g., 100 lines of code updated a couple times a year) and large extensions (eventually, third-party applications) to probably want to self-host on their own Phabricator instances in most cases.

The immediate goal is just fixing the problem that distributing extensions is a huge pain and all solutions have major downsides, with "convince the upstream to accept the extension" being the best option for everyone but us. The new distribution mechanism would be:

$ arc lint
Okay, automatically installing all the extensions this project needs.

(...prompts if you need to trust new stuff...)

Done!
...
nice lint output

Which fixes distribution. In the long run, there's a lot we can do to build stronger ecosystem tools, but I'm less worried about tackling that stuff today than I am about moving distribution to a broadly reasonable mechanism.

From D17067:

That didn't seem to be the case. It might have been because we only enforced Google authentication around one year ago, before that users could use a password for authentication. I can check later today, but perhaps the users that ended up with duplicate accounts never setup Google Auth.

To provide some additional context, we originally allowed users to register their own accounts, but we eventually disabled this because we ended up with around 30 duplicate accounts (users with more than one account). I think that this happened because users had listed an alias address in their Phabricator settings, but Google was using a canonical email address to authenticate, which didn't map to any existing user accounts (we have a lot of users that have aliases set up. For example, abraham@mycompany.com would be an alias for the canonical alincoln@mycompany.com address).

Thanks!

I clicked "Update Now" and the update frequency for our most active repository has dropped back down to 15 seconds.

Sorry, apparently after running arc upgrade it no longer times out (although it does take a long time).

In T11699#195930, @chad wrote:

The error log says July

Server

• rP38b10f05a224d29c723c033dec0820f977aa8026
• rARC483e985d08d279816708a9e755de8e5c3586d3ba
• rPHU1a0371a2247a256d1e6e44d4f348adc2750a9788

Here are some query traces from XHProf: