On our install, this data is ~250MB.

I started working on this in D13094, but it's nowhere near finished.

I don't, but it maybe stops bad things from happening in cases where destruction takes a bad time? I was destroying a Diviner book and it took a long time so I ^Ced it and ran it again with --trace. I wasn't too worried in this case because Diviner books don't utilize a lot of infrastructure. But for other objects, this could be problematic maybe?

The approval queue is fixed, but it still doesn't log in the new user correctly:

Thanks, good explanation.

What's the difference between putting something in a space and setting the visibility of an object to "members of some project"?

Can we get a fund initiative for making Fund work like Kickstarter? :P

@epriestley, could we simply invert the logic of DivinerAtomQuery so that it returns undocumentable atoms by default (and add withExcludeUndocumentable(true) to all existing callsites?

https://secure.phabricator.com/differential/diff/31781/ seems to fix this, although I doubt this is the correct solution.

Adding PhutilArgumentParser and --trace gives me the following output:

Looks like --background is six times faster though: https://secure.phabricator.com/xhprof/profile/PHID-FILE-zy56ub2hhqqmrsgelvdl/

Here's a profile: https://secure.phabricator.com/xhprof/profile/PHID-FILE-6qploks2cyzbwune3vki/

The same thing applies to ArcanistDuplicateKeysInArrayXHPASTLinterRule.

Nevermind, this was some weird local issue.

OK. Apparently it also happens on this install as well.

This happens in Maniphest as well.

The user's user agent string is Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36

I turned on XHPROF sampling and grabbed some data:

Sorta... My issue isn't that indexing ElasticSearch is slow, rather my issue is that queueing tasks into the daemons seems to be slow (this shouldn't be touching ElasticSearch, also I believe this issue existed when we were using MySQL indexes as well).

It might be worth noting that I am running the ./bin/search index command on the same machine that is running our daemons.

Having a look at this and I can't actually remember what the issue is.

Diviner updates over Conduit would be awesome!

In T8352#117479, @epriestley wrote:

(There's also a uri.source in Books which should probably get an implicit value if the repository is set but uri.source is not.)

Yeah, it definitely is a weaker relationship than the current "blocking tasks" relationship. FWIW, I think that JIRA has a "related issue" field (I could be wrong, I've never actually used JIRA).

Some things that are maybe worthwhile (in addition to the blocked tasks):

If it were to be automagic, there should at least be a way to remove related tasks... For example, someone might say This is related to T123 and receive a reply of No, this is a separate issue. In this case, we should be able to remove T123 from the "automagic related tasks" field.

Would it be valuable to record the repositoryPHID for DivinerLiveSymbol / DivinerLiveAtom as well? Furthermore, are you able to explain the distinction between these two classes.

T7604 removes the "Arcanist Project" field, but we could show the repository instead.

@hach-que, this is what you were asking about in IRC.

I've changed the test plan of D13066 now, but here is the original text that triggered the transaction being created:

The issue is that I always forget to learn how to use this functionality until I want to respond to an email and then its too late.

I have no idea why this works through the web UI...

This happened again today (for my own future reference, see D20770 on our install).