I'll see if I can guess what's going on here; otherwise maybe I'll just sneak a look at things the next time I'm over there.

I also confirmed that there are no outstanding "nuisance" invoices for trivial amounts of money.

I pushed this change to the cluster and marked the four $0 invoices we'd previously generated as paid.

We now default to "ignore". It would be nice to add a confirm step eventually.

Specifically, I'd expect these unusual behaviors from these notifications:

My thinking on this is that we literally just send the user a notification, which shows up in the notification menu:

I think adding a "View in Column" button to the Conpherence dropdown menu (and maybe making that menu show a few more items, like 10 instead of 5?) could push the specifics of this out.

I do expect this general class of behavioral stickiness overall, but I'm not sure how valuable sinking the effort in to get all the fine-tuning and details of draft stuff working ahead of other refinements (like showing threads with mentions or new messages) is.

I'd maybe start with this:

"Automate your companies process" should be "Automate your company's process", unless i'm wildly misinterpreting it

Thanks, I'll run this down.

I'm increasingly thinking that T4245 may also make "clone/checkout as" globally unique and allow it to serve as an alternate identifier, too, although that's a little messy.

In prepration for T4245, we should probably be moving this stuff to accept IDs, Rxx, rCALLSIGN or CALLSIGN, and getting the abstractions for that in place if they aren't already.

I like at least trying the last item as a dropdown. There are a couple of other similar "make UI elements work better on mobile by default" things too (T5752) that I sort of want to clean up, but holding these until after the redesign probably makes sense.

Specifically, this was almost certainly fixed by D12401, which is a little more than a month old. If updating Phabricator doesn't resolve this, let us know.

I made the "likely" edits locally without hitting an issue:

Does this reproduce on this install, or only locally? I can't immediately reproduce it.

I think Fixes Txxx (and other closes-when-landed relationships) is strong enough to imply this, but it feels a little unexpected with just ref/mention.

What version of Phabricator are you running? You can find it in Config → All Settings in the web UI. It looks like this:

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.

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).

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.