Here's roughly where I'm headed next. I'm planning to:

The "default" controller currently needs to "force" the URI parameters...
The "filter" controller currently needs to "force" the URI parameters...
The "apply" flow, where a new custom filter is applied...

A couple of weird cases on state management:

This is sort of generically concerning to me:

This is deployed everywhere now, and kicking secure004 over seemed to work correctly, at least.

This stuff is all deployed, now.

cd provides "at least once" delivery guarantees.

This incantation seems to work as an upstart job:

I'm going to install an upstart task on secure004 and kick it a few times, some stuff might be sketchy until I figure that out.

Support multiple request encodings (likely BSON, protobuf, or messagepack). Leave JSON as the default, but in cases where messages can not be represented in JSON this gives us a plausible way forward.

The stalled production backup process completed successfully after deploying the change.

See also PHI1318. The new behavior here has tightened our rules about which users we act as.

I'm going to try to sneak this out to the db tier to resolve things before the west coast wakes up, at least.

PHP Fatal error: Out of memory (allocated 311164928) (tried to allocate 105988097 bytes) in /core/lib/libphutil/src/future/exec/ExecFuture.php on line 246

See one followup in T13326. The "import from disk" part seems to have worked properly in production.

I just ran into this for the first time:

I've also never seen anyone use kill -TERM `cat /path/to/pidfile` in real life over some flavor of pkill, which is basically the same thing as "pattern match the process titles".

provided I'm not missing some secret reason to retain PID files.

I've marked D20604 as resolving this; it does so by making bin/phd status report local process status only. I strongly suspect that this is probably a better / less confusing behavior.

I have a patch for this which basically says "don't try to kill any process which doesn't look like a daemon process".

This is probably somewhat entangled with T13253 and/or T11037 and this whole thing is kind of a mess.

We've run instances in the Phacility cluster for a long time now, but this is generally not something we really support or plan to support since there's no real customer interest in instancing Phabricator.

The power is in my hands, now.

But wait! It says there are two ways! The other way is:

If you are just writing an upstart job that needs to start the service after the basic facilities are up, either of these will work:

start on (local-filesystems and net-device-up IFACE!=lo)

This was effectively resolved in 2019 Week 17 (Very Late April). Now, only ancestors of "Permanent Refs" trigger any publishing behavior (audits, notifications, feed, etc).

This is very old and it doesn't look like we ever found a working set of reproduction steps.

🐫 Does this button work ------>>^^^