when i run the command:

Why do you believe that files which are split into chunks don't get encrypted?

phabricator b9f35351e9d486f7b825652ba2de0074b35cd2c5 (Aug 29 2016)
arcanist 10e5194752901959507223c01e0878e6b8312cc5 (Aug 26 2016)
phutil d6818e59c1764ede22cad56f8c5b1b527cb6a577 (Aug 26 2016)

I'm sorry you feel that way. These kinds of requests are frustrating for us too, which is why we try to make it clear upfront in the documentation that this is not an appropriate forum for them.

I'm disappointed by this response.

Since it doesn't seem like the documentation is incorrect anywhere, this doesn't appear to describe a bug in Phabricator which we can accept upstream. See Support Resources and Contributing Bug Reports for details on what we do and do not provide support for.

I think you've already mentioned the right answer for my initial question (though I'm not in a state to try it out just yet): arc close-revision. But that's not obvious as an alternative to closing out a diff.

Additionally, coming to phabricator, my expectation is that arcanist would handle the front-end (i.e. phabricator), but not strong-arming my local development environment.

That document says:

I was attempting to follow what I understand as the (abbreviated) standard process for a review:

What led you to arc land, specifically?

Also possible is stuff like "the diff has a custom policy which you destroyed", etc.

If an object exists but is failing to load, it's usually because a required related object does not exist (in most cases, "required" means "required in order to evaluate policy checks").

Thanks for responding, Evan.

This isn't a bug -- I think we've just set you up with the wrong expectations somehow. There's probably some sort of documentation we can improve to make it more clear what arc land does, and maybe I can figure out how where we led you astray by asking some questions:

I believe I've seen these exceptions for the past year or so on our setup as well, though I hadn't actually confirmed the diffs do exist. I did confirm that nobody ever manually deleted diffs though.

Yes, thanks!

This has been solved AFAIK since I haven't seen this issue in a while.

I'm going to presume we got this, but reopen or yell if you're still seeing issues on the new code.

Thanks for the report! The detailed reproduction instructions were very helpful in resolving this.

Thanks!

Please see Contributing Bug Reports for what information is required for bug reports.

+1 it's very confusing

testing

I'm following up with the one who reported this to me.

hghg

[[ http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url] | name ]]

name

[[ http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url] | name ]]

aman

http://[url=http://www.test.com/" onmouseover="alert(document.domain)" ]http:="" a="" "[="" url]"="" target="_blank">http://[url=http://www.test.com/"/onmouseover="alert(document.domain)"/]http://a/"[/url]

name

I can't reproduce it anymore I'm afraid. Before I posted this I tried deactivating the repo, disable/enable the URI to no avail.
After I posted I removed the repo from the command line and recreated it from scratch. It now works. All the details are the same (I'm using a private key).
Works fine now
-\o/-
I've added other repos, observed and hosted (public and private) since posting and they work too. I don't know what caused this to happen on the first repo I created but I can't reproduce it since doing the remove.

Not sure how this was set up, but I noticed this in the logs.

How can I reproduce this locally? See Providing Reproduction Steps for help on providing reproduction steps.

Found something to reproduce this problem, or at least, I assume that plays a big role in it:

To accept this report, we need reproduction instructions we can follow to reproduce the issue locally. See Providing Reproduction Steps for details.

I think this is entirely reasonable.

Actually, the problem seems to be in the system configuration. There a hard limit on open file descriptor ( which limits mysqld to 214 connections.

After setting max_connections=1500 , the problem still happens some hours after running the instance.

this entire menu will likely go away

Unicode has a page of heiroglyphs but they don't seem to be supported yet on OSX.

Actually, I don't think we can really style the numbers of a numbered list independently of the rest of the list. They aren't directly addressable with CSS and the approaches I've found for doing it rely on using counter(...), which I think is unreasonably complex for this use case:

151 seems to be the common default.

We have seen exactly the same error on our instance today, since updating to master. MySQL max_connections was set to the default of 151.

max connections was set to 250 (default?). We bumped it up to 1000, which seems to have fixed the issue for now.

Ah! Thanks, we'll get this fixed.

See Contributing Bug Reports if this is intended to be a bug report.

Does raising max_connections in /etc/my.cnf (or similar) and restarting MySQL resolve this?

I can confirm that this bug also happen on a local install with a few users (around 15)

GitHub also does this:

We made one change recently (T11672) but that should cause us to use fewer connections.