Okay, here's what I did to try to reproduce this:

When APC/APCu are not available, we fall back to a disk-based cache with worse performance characteristics and much worse cache semantics than APC/APCu provide.

Adding one is probably the easiest workaround for now.

Aah, okay, I misunderstood.

There's a vaguely related but much less severe issue where the list view can take a long time to load because it needs to pull a bunch of files off S3 in order to generate the content caches.

I have restarted them several times, if I keep hitting a single page it comes and goes.

Ohhh! Sorry, we usually use "preview" to mean "remarkup preview" (the comment box thing at the bottom of the page) and I figured you were putting {P123} in a comment and getting slow comment previews.

From T9566, these are probably 1MB JSON blobs from API calls.

This message should go away when you've ignored everything.

I'm still just working through this with CircleCI support. No real headway yet, turnaround has been ~24+ hours every time so we're still just discussing the problem.

We're an open source project with a small team, and can't spend time working with individual installs to debug unusual issues that are specific to their environments or support old version of Phabricator. If we accepted these kinds of support requests, we would spend 100% of our development bandwidth debugging bizarre setup and configuration problems which affected single installs.

This has been in stable for more than a month without any followup issues cropping up.

I don't think that use case is strong enough to justify making this mechanism more complex. Some ideas:

There are a couple of minor followups between this original announcement and HEAD which improve some behaviors, but this has been in stable for about a month now.

Closing because we aren't able to reproduce this.

We may have some support for this after T1562, but probably will never have sufficiently granular upstream support to solve this particular problem. I don't anticipate ever disclosing who cloned things in a web-accessible way.

No.

I'm not sure why our workaround for this in rPHUe9fea5c64c0c wouldn't work for you, but it seems to work for other people so I'm going to chalk this up to something else in your environment until we see more reports.

Are you certain these tasks aren't being removed automatically? The expectation is that they will naturally fail over time when they are unable to load the corresponding commits.

Closing as unreproducible.

When we generate a synthetic diff between diffs "A" and "B", we just use diff and do not apply any move or rename detection on top of it.

Presuming that answers the question, let us know if not. T7148 is the general production task here.

Just collecting some more related stuff here: D14298 adds a .arclint-configurable version requirement check, which currently executes as a side effect of getCacheVersion().

Yeah, T4026 seems like a reasonable path forward here in that there would exist a relation for "commit X addressed concerns raised in commit Y".

(+@colmdoyle, you expressed interest in this elsewhere.)

I think we always get that gap between the header and body in mail, too (even for non-counterexamples).

That fix is close, but probably not quite right, because a user might be able to create a subtask without being able to edit the original task.

From D14273, @gd also got a substantial performance improvement for long input lines applied to the Pygments upstream:

That was just some random demo user clicking buttons. I'll merge 'em.

What's the syntax to have a propoer field header?

We parse fields until we encounter the next field header because clients may linewrap, so the message above has a "Title" field with value change, and a "Differential Revision" field with value https://phabricator.collabora.co.uk/D244 refs T2495. This isn't a valid revision identifier so we can't figure out what to update.

This is intentional. arc diff --verbatim is the flag you want, or use arc diff --edit to edit from the CLI instead of overwriting your Git commit message.

I can't reproduce this. Here's what I did:

• Make these changes in PhabricatorPygmentSetupCheck.
  • Instead of running pygmentize -h to test that Pygments works, run pygmentize -V. This will let us test that the binary works, but also let us check the version.
  • After doing the existing "Does pygmentize work?" check, try to parse the version:
    • If we can't figure out what version it is, assume it's a future version of Pygments that changed the format of the version string and do nothing.
    • If the version is 2.0.0 or newer (you can use version_compare() to check), do nothing.
    • If the version is older than 2.0.0, recommend upgrading to a more recent version of Pygments to get support for more languages and improve performance. Advise the user that they can safely ignore this warning if they don't want to upgrade.

I'm continuing to work with CircleCI support on this, but no headway yet. I imagine they're still handling fallout from the recent service disruption.

ApplicationEditor (T9132) and Nuance (T8783) are both scheduled for implementation before the end of the year and might offer alternatives here, too. With ApplicationEditor you could create 500 "create task" forms (instead of 500 teams) and have each form prepopulate with appropriate assignees, subscribers, projects, etc. With Nuance, you could create 500 queues (instead of 500 teams) and give each queue custom routing rules (and potentially have them just create tasks directly and not actually use Nuance).

One note is that the transcript cost only includes the cost to evaluate the rules, not the cost to load the rules. The intent of the field was to catch rules which were unusually expensive to evaluate, but in the case of a large number of very simple rules, I would expect that the cost to load and build objects for rules would dominate the cost to evaluate them.

In many cases, we must run Herald rules synchronously in the same process performing a write which triggers the rules. In some cases, this is strictly required: for example, when you push a commit, we clearly must evaluate at least some rules before we accept it, because a rule may say "don't accept this commit". If a rule may cause a "don't accept this commit" effect, we obviously must evaluate it before we accept the commit.

It's vaguely possible we'll pursue this eventually, but I doubt it, and any such support is years away.

Would this work?

Unsatisfying conclusion here, but:

In T4721#53743, @epriestley wrote:

And we should possibly consider splitting the permissions more granularly:

• View
• Show Secret
• Edit

• I closed the 003 nodes to new allocations and opened the 004 nodes.
• I created a new test instance and verified it allocated on the 004 nodes.
• I vetted backups, login, web, repo import, and daemon behavior on the new 004 nodes.
• I also pruned some older test instances off of the 003 nodes and cycled them to give us a little more general headroom on repo003. Load should stabilize over time as more test instances suspend over time.

I brought these nodes up normally, they're deploying now. I'll swap them over and vet things once that finishes up.