Comparing the mappings before and after (with curl 'http://localhost:9200/phabricator/_mappings?pretty=true'):

I've made some small progress here.

You may want to try running the stable branch instead of master:

Ah, sorry, I was mistaken. Our CloudFront setup is actually more involved than the documentation implies. This host has a simpler setup but uses CloudFlare, not CloudFront; CloudFlare applies weaker SSL certificate validation rules. Here's how we fix the headers before the request runs:

Generally, the expectation is:

Actually, I think the setting I pointed out is unlikely to affect behavior here. I'm not sure how the request is reaching your server with a "Host" header which allows Phabricator to serve the request. Are you forcing this on the server (e.g., overwriting the inbound Host header with the "correct" header)?

Is Behaviors → Edit Behaviors → Forward Headers set to "None (Improves Caching)"?

Specifically, the problematic workflow is this:

This workflow is inherently unsafe, and can not be made safe.

From T9190, this may not actually be specific to the cluster.

In T9161#131941, @chad wrote:

My 'useful' bar for email is "would I want to reply to this".

I'm going to wait until the Harbormaster doc gets split up a bit before writing details on how to use this, but here's the rough version.

Yeah, there's no way to connect a third-party tool to application-level metrics like queue length right now.

I don't think macros are necessarily a bad idea or anything, and they'd be an OK fix here, they just seem potentially really complicated and involved and like they're only-an-ok-fix for a handful of not-too-important issues.

The primary use case I see for {!bigproject/presentations/pitch.ppt} or {!design/mocks/notifications.pdf} is non-version-controlled resources which are potentially shared between users and updated a lot of times. But basically the same value as Drive or Dropbox: sharing files with familiar filesystem semantics so you can go look in a folder and see stuff with sensible names and non-technical users have a reasonable shot at figuring it out, too.

I suppose an example from the original ticket was:

I don't want to solve it anytime soon (and don't actually understand it, see bottom).

Even setting aside the intentional "Yes" -> "No" template edit, subtle changes to macro text over time could render it meaningless/confusing on old tasks.

So the idea is that you can either invoke a snippet as a macro, like:

Like, there's no useful {{changelog}} macro I can define, since tons of the internal text is different from page to page.

Well, what would the changelog one look like? If it looks like this:

I can create a "weekly_changelog" template which I use in Phriction to quickly apply the common markup I use when building a new Changelog page.

I'm planning to take these corrective actions:

Some contributing issues:

I cycled the host to trigger compaction and bring everything back up, which seems to have resolved the initial issue.

Getting arc test to use whatever method arc diff does for deciding which test suites to run

Just to clarify, you really mean arc test and that isn't a typo of arc unit?

In fairness, you can't dead them either.

Why are users updating revisions if they don't want reviewers to look at the changes yet?

Thanks!

A couple other things we could use soon in the upstream, although not requirements for v0:

I can sorta fix with using PhutilFileLock, but it feels a bit gross. Here is something I threw together real quick: https://secure.phabricator.com/differential/diff/33545/

The configuration-driven unit test engine isn't yet ready for general consumption.

Thanks for the report! I think your analysis is correct. D13893 should fix this.

T8612 is related.

I guess that we should return a 404 (or even 410)

Why would it reproduce consistently for certain diffs but not for others though?

We do record the originator of the mail internally, and could expose it in /mail/ or bin/mail volume, etc., without much work. For example, it would be easy to add:

bin/mail volume doesn't report what fraction of mail is generated by the user, if that's what you mean.

Yeah. I'd also really like the objective numbers from bin/mail volume, but they won't be very good for 30 days. Maybe we just wait that long to attack the "too much email" aspect of this -- role profiles and herald outbound rules are justified on their own anyway. I'd want to get this data:

Put another way, "send no mail by default" solves a different problem, which is "administrators complain to us that their users complain to them that they get too much email, but some of this is rooted in personal/emotional issues and has no technical/product solution".

I think there are a lot of reasonable things we can do to make it easier to get your settings set the way you want them, but they'll only help users who have a "oh, these settings aren't very good, let me go fix them" mindset. My concern is that the root of this problem may not be users having difficulty setting things up, it's users just feeling helpless and overwhelmed by the problem for essentially personal/emotional reasons which we can't easily fix.

One thing that I'll probably do for Herald, at least, is group some of the tags up so you can write this rule:

I think arc patch has some old, sketchy code around authentication. The problem is that arc patch is currently unique in that it wants to use authentication if it's available, but does not require it. This never really got built properly and is kind of a hack job.

I'm close to interacting with this stuff on Herald outbound rules -- do you have a general attitude toward the future of mail tags?

Cool, thanks for the followup!

I think projects/badges are a better approach for this.

Do you want this capability in general, or all your intended use cases also account attributes (e.g., administrators)?

Yes, T4103 is the task for this. I'm going to merge this there.

We could also split projects into two completely separate but essentially identical applications, "Groups" and "Tags". In the simplest form, both applications would run exactly the same code, except one would say "Groups" everywhere and one would say "Tags" everywhere, and each object would have an internal type flag specifying whether it is a "Group" or a "Tag".

Why are you destroying wiki pages?