P2028 is a really quick bookmarklet that will pull the content of a given Phriction document and insert it into the current Phriction edit page's textarea. Hopefully it'll save a few clicks for those of us who write lots of pages with a similar structure.

My workaround for arcanist:

metamta.email-body-limit is unset.

Also, is metamta.email-body-limit set to something crazy? I think that only means main-body (not body + attachments) right now, but it should probably mean body + attachments + headers.

Oh, never mind, that's the Differential patch responding to the commit, so metamta.diffusion.byte-limit isn't relevant.

Thanks, I'll take a more in-depth look at this.

JIRA actually seems fine: arc, web UI, and both the integrations (link / post) work properly for me at HEAD of master.

Wow I feel the same way as @lunderwood. The problem is that it now happened for the third time and users send me screenshots of how their upload didn't work. But the permissions are all correctly set up. But then it works again after some time. It's a bit frustrating.

I've been also playing with the shellcheck linter and evaluating it using the following .arclint entry:

I had a look at other bug reports. It looks like I am not the only one having this kind of problems. So it seems that hg >= 4.x is not supported yet, and actually not even the whole 3.x is supported.

@gabe - That's the same issue, I believe. You should be able to push using Mercurial 3.4. I've been meaning to do some testing to try and fix this over the winter break but a day is no longer what it used to be.

Not sure if this is the same issue, this is on a new phacility hosted phabricator instance, when attempting to push to a new mercurial repo:

Aha -- the diff as posted for review was mostly-reasonably sized. The diff as committed was the huge one:

mysql> select differential_diff.id as diff_id, creationMethod, SUM(addLines), SUM(delLines)
    ->   from differential_changeset
    ->   join differential_diff on differential_changeset.diffID = differential_diff.id
    ->  where differential_diff.revisionID = 253041
    ->  group by differential_diff.id;
+---------+----------------+---------------+---------------+
| diff_id | creationMethod | SUM(addLines) | SUM(delLines) |
+---------+----------------+---------------+---------------+
|  837437 | arc            |         11845 |          8567 |
|  837558 | commit         |       1752986 |        396108 |
+---------+----------------+---------------+---------------+

bin/worker execute --id 35362582 did not work because the task was archived. Instead I ran ./bin/phd stop; ./bin/worker retry --id 35362582; ./bin/phd debug PhabricatorTaskmasterDaemon. The key seems to be the production of the .patch file itself, not the number of files. Somehow these users managed to cram a >100M patchfile into Differential:

thank you @avivey.

The grouping is probably random / first in the list. There's no concept of"primary/main parent" either. parentIDs/subtaskIDs constraint in maniphest.search should give direct parents/children only.

Thanks, I think D17097 should fix this. It isn't intended, and is just a curious artifact of some other behaviors.

Alright, I'm actually having trouble reproducing this. Here's what I tried:

I wasn't immediately able to reproduce this:

I strongly suspect this report has enough information to let us replicate the issue locally, so you don't need to take any further action yet. I'll follow up if I have difficulty replicating it and we can figure out what differs between my synthetic test case and your real environment.

Reference in PHP 7.1 migration guide: http://php.net/manual/en/migration71.new-features.php#migration71.new-features.asynchronous-signal-handling

See also T10208

We take design feedback during product launches, and no other time.

@chad Ah bummer. Is there an official channel you guys recommend for feedback of this type?

Sorry, we don't take UI suggestions as feature request tasks, but do value the input and will keep it in mind.

It will likely be easiest to replicate again after upgrading to Week 52 stable this Friday, since I can't use precise same diff, and don't know the precise set of replication criteria yet.

You can always create a test instance in Phacility, and upload the diff there - those are free and temporary - see Reproduction/Resources
There's also rGITTEST, although maybe it's not so good for a super huge diff...

We weren't running quite HEAD then, but we were running a version that was our patches on top of something about a week old -- see the end of the description of T11743, which was the first report in that chain. Our version today is a couple of months old, so I see why that'd feel different.

Hm; we weren't running HEAD when we reported T11748. We have an upgrade planned to latest-stable in a week or so -- will that be sufficient to re-test with? Or is there a repository that we can apply a 4,800-file diff to on Phacility?

Please update to HEAD before filing a bug report. We can't take reports against old versions of Phabricator. You can use Phacility if you'd like to test an up to date installation.

You can create your own link to tasks in a few seconds; the extension above will reduce this further. I don't plan to bring a global, hard-coded "Open Tasks" link to the upstream.

(2) and (3) are correct.

Probably should be two separate tasks. 1 is implementing some sort of "global" menuitem for projects. The other is adding group by queries to workboards, which I think is already covered in another task.

I think global + personal makes sense -- we'd want to put stuff like "New Bug Report" / "New Feature Request" there on this install, I think.

In T550#202580, @epriestley wrote:

Multiple hostname stuff: Today, the SSH hostname of an install and the HTTP hostname do not need to be the same.

We use this in the Phacility cluster: Phacility HTTP instances are at instance.phacility.com, but serve repositories via vault.phacility.com.

The technical reason for this is mostly that ELBs can't accept port 22 traffic -- or couldn't when I set them up. It looks like new VPC-ELBs may be able to accept on 22. We currently use HAProxy to balance SSH traffic and ELBs for HTTP traffic.

We could require that all hostnames be the same and change the cluster to bounce SSH traffic through the ELB to the HAProxy LBs and use new VPC ELBs, or put HAProxy in front, or whatever else. But this is probably more work for us than letting them differ.

There are also some possible arguments for using a different hostname for Conduit CLI SSH access (conduit.whatever.com) that has different DNS-based load balancing behavior than other SSH access.

The real working example

I've been playing with it for maybe half an hour, and couldn't reproduce:

• Made revision public
• stopped the daemons
• mention a user
• updated the revision to a new diff
• made the revision not-visible to that user (visible only to the acting user)
• start daemons and let them finish the queue

Thanks for the advice. That yields the trace below. My understanding is that it was a diff with policy set to subscribers which had an author plus a single subscriber. That subscriber was added by herald upon the diff's creation, so there's certainly grounds for something going on there. I had trouble divining the exact issue, but tinkering with the permissions for the object ended up letting the emails go through.

We used to have a tool to show a task's data, but it must have gotten lost in some refactoring.

• In Daemons, find the task ID in the leftmost column of "Leased Tasks".
• Run bin/worker execute --id <id> --trace to execute the task in the foreground.

That will give you a more detailed error information which you can paste here.

Just updated to head and am seeing the same issues.

I know it's closed, but here are few proposals (not sure if better in any way):

• base
• derived / derivative

The API is considered unstable and there seems to be work to do about this manual transformation from arc lint --output json (which isn't even JSON) to harbormaster message JSON format.

I think these are all reasonable things to want to do.

There may be some merit to changing the UI to say "Title" or "Error Title" instead of "Message", but this is so low in terms of value ("Admins that don't read docs confuse fields") that I doubt this will actually happen.
Changing the API is even less likely, because that will actually break other people's code.

Partially it is. I remember now, I've fallen in this trap the second time now, I forgot what name is (again, btw). I told you that name is too generic. The first time I found out that Message is a wrong title for Linter rule name and worked around it. This time I forgot it again, because the terminology is not consistent.