Ah nice.

I haven't actually done anything on this.

This will be much easier to test after T8042.

We have logic to determine the repository already (you can see it at the user-facing level in arc which, for example). You should just be able to remove projects completely, I believe.

@epriestley, do you have any idea how Differential would work without Arcanist Projects? My only thought is that we could do some sort of Conduit call to determine the repository. Probably this should happen server-side I guess.

Your version of Phabricator is from April 16th. The "link" field type was added about a week later, on April 24th. See D12543.

What version of Phabricator are you running? You can find it in the header in Config → All Settings. It should look like this:

We run a large number of SQL queries, including large SQL queries, and hold a large number of connections open simultaneously. On a properly configured database, none of these behaviors should abort other unrelated connections.

I notice /opt/bitnami in your path. If you're using a Bitnami image, you should seek support from them. We do not offer support for third-party packages. See T4200 for some discussion.

You can edit the task description and add whatever links you want.

No. There is no task tracking that. T3578#90847 has a small amount of discussion.

Maybe more in-line with that intent would be "orange dot = away for less than X hours". That information is available by clicking through, but not part of the dot. But that doesn't cover "I'm working, but have family in town and will take longer than usual to respond". See more discussion in T8183.

Thanks.

• I added logrotate configuration as part of the deploy process for hosts running apache.
• I added swap configuration as part of the deploy process and enabled 16GB of swap for repo-tier hosts.
• Things have been consistently stable since making the original changes.
• I also recently added more billing-status review tools and pruned a bunch more demo/test instances, which gave us more headroom here (host load is currently hovering comfortably around 0.60, with physical memory only about 90% consumed).

We should fix this permanently since this is something like the third time we've hit it and it's super dumb that this mistake is possible (you'll hit this pathway only if your email is configured in a certain way). Some possible approaches:

I've removed this error completely (see rPHUbd087f55).

Out of curiosity, why do you have the same repository imported multiple times?

Seems fair enough. I'll take a crack at this seeing as I implemented a lot of the revert stuff.

I'll headed to bed right now but I'll probably fix this tomorrow morning and cowboy commit it before deploying, just a heads up for when that lands.

I also realigned the use of DNS. We now use:

I've converted the bastion host to an m3.large instance.

Deploying a bastion host now synchronizes account, key and sudoer state automatically.

Depending on exactly how T8026 sorts out, we might also have a stronger "public event" vs "private event" state in the future.

In T8209, we hit an issue where a migration performed a cache fill as a side effect of loading handles. This created a problem because the cache fill happened from a migration that runs before the cache was introduced.

In the long term, I think we should probably add an interaction with T4571 to reduce the likelihood of these issues. I'll make some notes there.

D12857 should fix the issue with list views (including /upcoming/).

Ah, thanks! I'll clean that up.

One other signal we could use is adding or removing backgrounds from icons, if we add them:

Few different parts:

... on the host

I'd exec ssh directly. If there's some major advantage to using libssh2 (but what?), I'd possibly use that optionally if it was available on the host.

Should be fixed in HEAD. Thanks for the report!