Yep, this is correct. Context is that there's no difference today between 'r' and 'w' connections. Distinguishing between them (primarily so we can send some reads to a replica) has always been a theoretical far-future goal, and I think we're mostly consistent about connection use in practice, so this piece hasn't been built yet. Building it would make eventual replica reads easier.

Can you try restarting apache (or php-fpm) and see if that resolves this issue?

This should be resolved at HEAD.

This should be resolved at HEAD.

This should be fixed at HEAD.

I think this is solved by D13292.

Turns out these are type-by-type, so yell if you see more and I'll just close this sooner or later if nothing turns up.

Oh, sure, that makes sense. So maybe not "valuable indefinitely", just "valuable until Diviner can extract symbols from a bunch of languages".

Actually I fnd the "pipe CTAGS" use case odd. I think it would be more useful if you could just run diviner generate inside a directory and we automatically generate symbols and documentation (unless you disable one or the other perhaps). In particular, this could maybe let us generate documentation stubs for languages we don't know about.

I actually can't reproduce this immediately now, either.

D13277 touches on another case for this which I hadn't considered in T6823: code blocks in Diviner articles. That one feels pretty relatively strong/compelling to me.

At this point, I'd guess this is probably something real dumb like us rendering the text forms of these wrong.

Ah thanks

I wouldn't expect this to have changed that -- see T4345.

Is it expected that I still receive "Unknown Object" emails? I thought that this task would've solved this issue. Specifically, I received the following email from this install:

In Wikimedia it occasionally happens that we do things in private ... but usually the fact that we're working on something in private isn't private in itself

I suspect it may not make sense to totally merge them -- particularly, I think the "pipe CTAGS into some script" sort of use case is valuable indefinitely.

(It sounds like @lpriestley helped you resolve this specific issue.)

It looks like these have required you to type in monograms/object names (not acted as typeaheads) since late 2013, when they were last touched (D7823). Their behavior doesn't seem to have changed, and still seems to work fine.

I considered putting a getClassName() method on the XHPASTNode class, but I'm not entirely convinced that this is a good idea.

This now works, and the upstream has implementations for the reasonable-seeming use cases we've seen, particularly the policy that blocks T8488. This is relatively modular and extensible, but I don't think there are any other problems for it to solve right now.

Assuming this is a misfire on "wiki", not an actual Wikimedia request.

This got raised to "Normal" so we could brand Phacility on admin.phacility.com

I think that there should be a separate visibility policy for the description page of a space.

Oh, and on these cases:

The rest of Spaces is on more solid ground, now, so I'd like to keep working on a path forward here.

I think this isn't a very good use case for batch editing. This is an unusual administrative operation and probably best accomplished in other ways.

Development Log

@Krenair, maybe you just don't have your preferences configured on this install in the way you expect? From the logs, it looks like you were sent mail with links in it:

Awesome! Let us know if you run into anything.

(I can't reproduce this, don't see any queries missing keys in the query plan, and haven't seen reports from other installs, so this isn't an upstream priority.)

And:

Sorry, we don't offer support for writing custom extensions or applications. See T5447.

I'm unable to reproduce this problem. We routinely run daemons for long periods of time without issues. See:

Let me write up a guide on how to use the performance tools and we can start there.

This seems to have resolved itself (after I pushed?) so I now have zero repros. Assuming I am just insane.

Both the UI and function of these transactions should be fixed at HEAD.

This is intentional: batch operations are just a more convenient way to apply normal operations to a large number of tasks. They respect policies, trigger Herald, create transactions, generate email and notifications, and cause other effects.

So far, I have come up with two different approaches to this. One of the major issues with this change is that we don't have a way to just connect to an arbitrary database with Lisk. Migrations which expect to change the phabricator_pastebin database, for example, cannot use PhabricatorPaste (which tries to connect to the phabricator_paste database, which doesn't yet exist). Furthermore, theses migrations cannot use LiskRawMigrationIterator either, because there is currently no easy way to construct an AphrontDatabaseConnection which connects to an arbitrary database.

One issue I hadn't thought about with using T5681 for this is that (without further changes) we'd have to create a new custom Policy object for every private thread, and they'd each be "different policies" with their own PHIDs. This would be OK for the most part, but feels a little icky.