Couple of years ago the furnace wasn't working so well. Light comes on, three reds. Pressure switch stuck open. I take off a panel, pull the pressure switches. The contacts close properly. No clue what's wrong. Call an HVAC guy. He's pretty busy. No problem, we got plenty of sweaters. Ha. He makes it out early the next week.

... condensate drain ...

...there's enough absorbent material underneath the sink...

I can't see a way to make the trap be any less garbage than it is because the 4" flanged tailpipe (the shortest flanged 1-1/4" tailpipe I could find) plus an additional 8" of tailpipe underneath it (the only 1-1/4" branch tailpipe I could find, which is only available with a slip fitting) means that the bottom of the lower tailpipe is super low. It looks like I left an extra 6" of flexible pipe on the drain side for fun, but that's just the rigid bottom of the tailpipe plus the minimum bend radius without making the flexible pipe start to crimp -- the bottom of the tailpipe is like 1-1/2" below the black plastic retainer clip.

Since there's no fresh water supply to the dehumidifier I don't think there's much benefit to an air gap, as there's no way backflow could ever contaminate a supply line. A clogged sink drain could possibly drain sink water out through the dehumidifier bucket, but the top of the drain line is only ~1"-2" below the top of the sink so it would overflow the basin onto the floor before very long anyway.

Other options I explored and rejected:

• Inline Comments: See PHI2217. See PHI2206. Inline comments don't currently attach images.
• Destroying Edges: See PHI2201. See PHI2217. Destroying files that have old edge types may raise warnings. The destruction still works, although it doesn't hit the edges.
• Destroying Files: See PHI2217. Destroying an object doesn't destroy corresponding FileAttachment objects, so you can end up with ghosts in the UI.

There are some remaining non-security bugs with this that I'll follow up on in T13682. I believe the security side of this is now resolved.

The details of this attack will be disclosed at a later date, once installs have had some sort of plausible chance to upgrade.

An earlier patch here (rCORE6d6170f76463) swapped binlogs to MIXED and set a 24-hour retention policy. This issue has not reoccurred in the cluster since that patch went out, but the root causes remain unresolved.

I filed T13687 as a followup for preventing this particular sort of error (where a Phobject is incorrectly serialized directly).

I patched and partially deployed this in early August. Another unattended MySQL upgrade went out on Monday night, also didn't restart MySQL on affected hosts, and caused some downtime on hosts that didn't have the patch (to "disable unattended upgrades"). I've now deployed this everywhere, and am presuming this is fixed until evidence arises to the contrary.

See also PHI2219, PHI2220.

That's very likely the same problem, and I think it should be fixed by updating to the current stable (rPf2a7db1 or newer).

...ideally this sort of thing should fail loudly at serialization time...

• The drydock_resource table could use a (status, ...) key to satisfy common/default queries.

After recent changes, only DifferentialRevision and ManiphestTask still have onboard mail keys.

"PhabricatorApplicationTransactionCommentView->setDraft()" has exactly two callers: one in Slowvote...

Resolved by D21824.

In T13588#256950, @cspeckmim wrote:

A user just ran into this exception with Arcanist...

I am pretty sure that this error message does not exist prior to PHP 8.1, and PHP 7.4 can not possibly emit it. See here for some evidence that this is true -- note that the error message is not present in the script output until PHP 8.1:

There may be additional work here, but presuming this is more or less resolved until evidence to the contrary arises.

I believe D21811 covers this completely.

When this mechanism is removed (by commenting out the logic that cares about the 25% limit), we'd expect Drydock to build 8 resources at a time (limited by number of taskmasters). It actually builds ~1-4...

We may fopen() an additional stdout and/or stderr handle, but do not fclose() it?

I am suspicious that D21794 may have broken something subtle with unix magic, since I'm seeing some hangs out of deployment scripts wrapping daemon management scripts. I think the issue is probably one of:

The outline above isn't quite sufficient because when the active resource list is nonempty, we don't actually reach the "new allocation" logic. Broadly, executeAllocator() is kind of wonky and needs some additional restructuring to cover both the D19762 case ("allocate up to the resource limit before reusing resources") and the normal set of cases. The proper logic is something like:

This issue partially reproduces (consistent with the original report, not immediately consistent with my theorizing about a root cause in PHI2177 -- actually, looks like both parts are right, see below): Drydock builds ~1 working copy per minute serially until it reaches a pool size of 5 resources. Then, it begins allocating 2 simultaneous resources.

What options exist for inter-process communication?

Here's how I'm thinking about overengineering this:

This was resolved as part of T13630. I didn't actually put it in the UI anywhere, but all requests will now originate from 13.56.71.101, and this isn't likely to change given the wind-down of Phacility hosting.

D21801, motivated by T13676, made this more practical.

This is somewhat resolved and neither next steps or motivation are clear any longer, so I'm going to call it done until evidence to the contrary arises.

Perhaps a philosophical question here is: do we care about which repositories are checked out in a working copy resource?

Before, instant reclaim after lease destruction: