I'm going to merge this into T9846 since I think they're the same, yell if it looks like I'm missing anything.

Thanks, everybody! Appreciate it, especially on a Friday night. :-)

Please read and follow Contributing Bug Reports carefully.

Also, test agents probably shouldn't be accepting revisions at all. But ¯\_(ツ)_/¯

Note also that differential.revision.edit accepts IDs and harbormaster.createartifact allows you to create links to build results without needing to gum up the feed with comments. We will eventually remove differential.createcomment so things will need to update sooner or later.

This should be fixed in HEAD of master and stable. Thanks for the report!

That does indeed work! Thank you so much!

Does this work?

Not easily. :/

Can you use the modern conduit calls?

This accidentally got fixed this week

That looks great to me.

Actual example output:

Yeah, with whatever wrapping context maniphest.search has, so like:

So should the return value for priority.search look something like this?

That is, the specific error "use lists" is aimed at preventing is this:

The config also looks like this right now:

I guess we already have "keywords" and should probably accept any of them, too, so "!priority high" in mail, /priority high in a comment, and "high" in Conduit all work consistently even if the actual key is "elevated".

Ideally, we should maybe freeze maniphest.querystatuses (which has a sort of ridiculous output format, I think?) and provide maniphest.status.search and maniphest.priority.search, which return results similar to other modern *.search methods even if they aren't implemented quite the same way (at least make the output format similar enough that a client library with methods like "turn a x.search call into a list of objects" would work on these methods, too).

It looks like what we really need is a new method like maniphest.querystatuses, called maniphest.querypriorities to avoid anyone trying to hardcode these values.

This bug report is missing version information and reproduction steps.

Cool, I'll update the docs.

Your suggested edit is correct, "disable" meant "switch to No I/O" but is misleading here.

A similar issue is that after configuring phd.user, you automatically get an SSH URI that won't work without setting up the other pieces required for working SSH clones. It's probably a little tricky to test all the various pieces, but maybe attempt a sudo -u <vcs-user> git help or something and create a setup issue on failure?

See also vaguely related T12590.

See also vaguely related T12171.

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.

I have an extra laptop I can use to test this.

And thanks for doing the legwork to pull a reproduction case out of this.

For context, we issue a query that looks like this:

haha nice. I just posted this comment on our downstream task tracking this.

fix is one line long :3

Thanks! This reproduces for me.

I couldn't find a project with multiple subprojects on this install otherwise I would have linked you to an example

We could also rip out all CSRF cycling code completely; Rails uses infinite-duration tokens with no cycling. However, the current code hasn't really caused any issues other than this for a number of years, I believe, and there are some practical-if-obscure attacks this can partially mitigate. An example is:

This will also fix the important use case where someone is running their browser inside a VM that they frequently suspend.

I believe that something in this vein is likely the fix:

Our behavior here is also legitimately wrong, and we can look at fixing this upsteam once we understand what's actually going wrong. I think if you dig in a bit you'll find a set of reproduction steps that are something like this:

Indeed there are the predicted error messages in the phd log. I will try to explore more and see what is wrong. It is probably related to the issue I reported (T12726), likely some of the fields are incorrectly created by arcanist in the first place.

All that makes a lot of sense, I will try what you suggest and see if that was the source of the evil.

I suspect this will not reproduce for us given the reproduction instructions. The code is structured like this:

Hi Epriestley,

Please use Conpherence or Ponder if you have questions about Phabricator administration and options.

Arcanist hides part of the stderr to prevent console spam. But what problem does this fix exactly? How is it a problem that 5GB of output are printed to stderr? The way I see it, if the tool called by arc prints a lot of info to stderr, it should be assumed it is printed for a good reason, be it 1KB or 5PB.

I don't think that's a very desirable behavior.

The same as what you do with any tool which produces 5GB of output: wonder what happened, then try again and redirect the output to a file and deal with it. Currently the user has to run manually the steps printed when using --trace, and then they will get to that 5GB output anyway.

How can I reproduce the issue you're encountering?

I have upgraded the version still having the same issue. Current version is given below.

The problem is a outdated version of phabricator/externals/mimemailparser/MimeMailParser.class.php.

What behavior would you expect arc to have if git commit ... produces 5GB of output (hypothetically, from a hook which prints 2.5GB of header and footer context and puts the important part in the middle)?

What if you try recreating the output generated by the hg commands shown from the --trace -- does the output look off in any way?

Did that, you can see the result at P2054. At least to me, nothing looks fishy...

Okay, Thank you.

(You are also almost 8 months out of date; we only support recent versions of Phabricator.)

Click on logout then tried to login using google authentication and getting the error.

Sorry for not providing the version information. I have included the version details below.

Please follow all the instructions when submitting a bug report. In particular, we need:

I am unable to login to my Phabricator after clicking logout. Getting the below error.