Hm, in your original report the stack trace doesn't mention DrydockConstants.

Ah, to recreate this you only need to add a build plan with a "Lease Host" step and you will get this fatal. The class referenced in the first message in the stack trace will be DrydockConstants and not PhabricatorWorkerArchiveTaskQuery though.

(Just clarifying the title since I thought "write protection" might mean something like makeEphemeral().)

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.

I have the same exception when I run ./bin/lipsum generate with the same error message.

OK, after creating a user I made some progress... but now I hit this:

Ah actually, this seems to only be an issue when there are no issues in the database.

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?

Why do you need to destroy enough objects for this to matter?

Hitting this again.

I think it was that phlog($ex) gives us the stack trace of the phlog() call, but if we have to pick one stack trace, the stack trace of the exception is more useful.

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

A clean-ish but very non-general fix would be to load PhabricatorStartup explicitly before using it in code which might be hit on a non-web pathway. It looks like PhabricatorAccessControlTestCase.php already does this.

There is an excellent paper by H D Moore [1] on the subject of security in
terminal emulators regarding control characters. After reading it, I got
inspired and created a couple of proof of concept 'attacks'.

I don't know that the requests are slow, just that they are CPU intensive (or maybe there are a lot of them?)

In theory, the new "Multimeter" tool may be helpful in understanding this, although we probably need to at least let you put an explicit date window on queries.

Yeah, real apps might be overkill for this.

That sounds reasonable, although a CLI script could suffice I think. ./bin/phid types for example.

Now that PhabricatorApplicationConfigurationPanel is modular, I'm inclined to do this:

I think I'm going to give up and use offset paging.

Specifically, I would expect to see something like this:

FWIW RHEL6 is on php 5.3.3.

My general thoughts are:

I vote for it.
For Namespaces, that is a huge undertaking, you basically scrap the current autoloading, probably go with a PSR-4 autoloader, and add namespaces and "use" to a bunch of files at once.