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

(+@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:

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

(We caught up in IRC.)

We can't reproduce this issue, other installs haven't reported similar problems, and you're about two months behind HEAD. Please refer to this document for instructions on filing an actionable bug report which we can help you with:

One followup in T9573 but I don't think anything exploded, otherwise.

I also tried using the ref name (refs/tags/phabricator/diff/123) and the tag name (phabricator/diff/123) as branch names without success, so I'm pretty sure this isn't fixable on our side.

This basically works, but there's a minor problem which I can't fix on our side that stops things from working: CircleCI does not git fetch --tags, and does not fetch the tag explicitly when building a tag. It does resolve the tag, but never actually downloads the corresponding commit. This means that tags and other refs which are not ancestors of a branch head (which is to say: everything in the staging area) are not buildable. I don't think I can work around this because we need the commit to be fetched in order to make it to the checkout: post: step.

I think I misunderstood and by "size" you just meant "point value". This will happen eventually as part of other projects work (T9378, T3670) but those need to happen first. I'm not yet sure if we're going to make this a first-class value or let you designate a custom field as a "points field" or something else.

Your expectation is that a card worth 10 points is rendered 10 times larger than a card worth 1 point?

This is definitely something which can be improved -- the transcript has been updated recently and is fairly clear ("Forced Mail", "...ignoring notification preferences..."). The /mail/ UI is fairly clear too, but hard to find right now. Other UIs and interactions haven't been updated as recently and aren't as clear.

See also this in the transcript:

aklapper (Andre Klapper)

• Mail Tags: This mail has tags which control which users receive it, and this recipient has not elected to receive mail with any of the tags on this message (Settings > Email Preferences).
• Forced by Herald: This recipient was added by a "Send me an Email" rule in Herald, which overrides some delivery settings.

Branch name issues aside, CircleCI still isn't running builds for me, so I'm going to have to shelve this for now.

CircleCI still isn't running builds for me so I can't reasonably do step 4 (the webhook part) tonight. Presumably they'll be back up by tomorrow and I can finish this up.

The test engine can figure out if --everything is present or not but I don't think it can reach up to the workflow object right now. So you can disable arc unit as a sub-step of arc diff, but not without also disabling arc unit when run without --everything.

We can use a branch name like "zzz_harbormaster" or something so the console doesn't clutter up too much.

Is running arc unit interactively ever desirable? Can you either disconnect the integration entirely, or have it no-op if the --everything flag is not present (if you rely on --target for build integration)?

Right. If you put it on multiple devices, we can't choose a single identity when you try to do anything with that key. I don't actually remember why we're even allowing that at all and suspect it's some legacy stuff from an early draft that no longer makes any sense.

No, it's more like this:

I think I just configured remarkup.ignored-object-names wrong when I added S3, should be OK now going forward.

Try the diff PHID -- $diff->getPHID()?