The first error is happening while we're trying to generate an error mail, so this maybe quite a deep rabbit hole, but that first surface error looks straightforward.

I've marked D14995 as fixing this, but only commits parsed after the upgrade will have author dates shown.

There's currently no way to create those relationships via the API (see T5873; see also T10034).

Oh, sorry, I was agreeing with you ("points to something environmental").

Yes, the trace implies your entire environment is unsound. RocketLoader (T9716), mod_pagespeed (T4854) and other technologies which rewrite page content and Javascript can sometimes cause this, if you have any of that stuff enabled.

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

In T4705#61706, @ott-consult wrote:

Yes, this would really be a useful feature. Especially as CentOS still uses a 5.3 version of sshd and on production machines, I would like to keep the "normal" sshd on the standard port. Using a different ssh port for all other tools require a lot of extra config.

Get a valid certificate or configure your system to trust your self-signed certificate. This is not a problem with Phabricator and I do not plan to support insecure SSL configurations in the upstream.

(I never tried to reproduce with Command + Enter because I always use Tab, Enter, and the symptoms seem identical.)

Hmm, it is possible.

@joshuaspence, is it possible that this was causing the issue you were seeing in T10004?

At HEAD:

I think chunked files shouldn't have produced errors on reads -- at least, the --dry-run was still clean for me on both hosts before D14981.

Testing has been completed successfully.

Oh! Well that would make perfect sense, then. I'll update D14984 to just clear all the headers that remarkup can emit.

I'm going to merge this into T5155, since the root issue here is philosophical opposition to the use of IAM Roles to manage credentials in the upstream. Two possible pathways forward outside of upstream support are:

I've realigned this around support for IAM Roles, because we now use a first-party client after D14982.

In T10110#152970, @chad wrote:

maybe just hr and h2

This request does not describe a root problem. See Contributing Feature Requests and Describing Root Problems for help describing root problems.

Oh, the comment was a screenshot. Inline + width should work on this host now.

D14983 fixes the interaction between inline and width. I'll push it to this server and wipe the cache now, and the comment above should start working.

You can look up the PHID with phid.lookup.

We should be in good shape to move forward here after changes in T5155. My plan is roughly:

See the Git documentation:

I do think we could reasonably put clear: both on hr and probably headers. I think it used to run into some problems with tables of contents, but we never (I think?) put them inline anymore (maybe in readmes in Diffusion?) so we should be in the clear, now.

Yeah. I think:

Wait this works now. Huh?

Points look great.

I'd like to put off building customization for as long as possible. I think we'll want it eventually to give custom fields broader support, but we can call all of that part of T418.

FWIW, here's what WMF's customized cards (by the Sprint extension, I think?) currently look like:

I migrated my development instance (~3,600 files from ~1 year of work -- I wiped the instance when we started doing instancing for Phacility circa Jan 2015) from S3 -> Disk and then partially back to S3 without any real problems, modulo an issue with chunked files. (Two files did error, but I found them in a different S3 bucket I'd used for testing a year or so ago.)

Dry run shows that some files are going to fail

(The case for doing this is weaker if it isn't for IAM Roles, but the S3.php thing doesn't support signature v4 (which AWS now requires in some regions) and the official SDK doesn't support older PHP, and having a first-party, future-based client will perhaps makes things easier eventually with T5544.)

Not at this time. This is far afield from our roadmap and we've seen little interest in it outside of your use case.

Can you just use an IP-based access policy instead?

I think there are two different issues with IAM.

Here's what I did locally. I wrote a rule to notify me about "dog" revisions:

Oh, I think this is because Differential doesn't fire Herald for comments.

Did your Herald rule actually fire? I don't see a step like "I looked at the Herald transcript for the revision and saw that it had fired, matched, and claimed to have forced delivery." in your narrative. That would be the simplest explanation.

You've created a subproject or milestone. You're strongly discouraged from doing this, and this won't work for a while.

Some of the older instances are beginning to collect enough data in MySQL to motivate this more strongly in the near term, especially as database data is currently stored multiple times on disk in backups.