This report doesn't have enough information for us to reproduce the issue. See the documentation here:

Why is this passing instead of failing?

Use arc which to understand what arc is doing and why.

Currently, these results are essentially never useful to anyone, so I don't think the proposed solution (adding difficult-to-discovery complexity to the typeahead) is very good. Instead, we should improve the quality of the search results. For example, only indexing top-level atoms (in PHP, classes and functions). I believe we already have the concept of "top-level" in Diviner.

Why are they failing?

(I believe) get a warning on the command-line if you try to land when tests are failing/not yet reported.

This would discourage people from landing in the situation where a diff has passed CR but hasn't passed tests.

T8644 also discusses writing a "recipe book" for Herald, since there are a lot of things like this which it's powerful enough to do but where the pathway isn't necessarily obvious.

Oh, I suppose there's actually no way to specify "Administrators", per se, right now. We could maybe add one after T8726 wraps up.

its information content is 0.

Can you use a Herald rule like this?

Do you still happen to have the original error message? That was unexpected, and the migration specifically accounted for the case of email collisions and I recall testing that case locally in detail, so I'm curious what I missed. The expected behavior is that that list wouldn't migrate (and would emit a message), but other lists would:

I can write a lock log for this but it's going to add a huge amount of complexity and basically amount to implementing locks ourselves from scratch. However, I don't see any other way forward.

Locally, edge destruction works correctly. Here's a complete log:

Can you also enumerate exactly what problems you have with bin/remove destroy on tasks at HEAD? The expectation is that all these relationships are destroyed:

This is almost certainly fixed by outstanding changes to Herald which are awaiting review. See also T8822.

We don't plan to restore actAsUser in any form to the upstream, since it violates policies and can not be made safe (in the sense of not-policy-violating).

T8833 is also "arc land should restore state after a failure".

It is currently intentional that arc land does not restore state after a push failure.

Yeah, I think we're likely to remove this. It generally needs a lot of effort to modernize even if we're going to keep it.

Try this:

I think I never actually enabled HSTS on this host. I've enabled it now. Clients should refuse to establish HTTP connections, mooting this.

I converted all the data destruction steps into a services wipe command. I'm planning to get the repo path stuff formalized too, then I'll update this with a simpler game plan.

This is likely fixed by further changes connected to T8726, which are currently out for review. I'll keep an eye on it.

It didn't, but nothing should be linking to http. How are you hitting HTTP links?

We could let specific "Important" badges generate a text tag like that but I'd like to be able to, e.g., award everyone who reports a bug a badge for it without turning every timeline into "Reported a Bug" on each comment.

Oh, yeah. That huge treatment might be good for "Administrator", "Employee" or object relationships ("Task Owner", "Task Author"), but feels pretty big for the more achivement-like "Made 100 Commits", "Registered for 5 years", "Contributed", things.

I was imagining something like this:

I don't want to do project/badge stuff yet, just an explicit "award this badge to this user" thing for now, but imagine maybe doing that in a future version.

We could maybe do exotic monograms (π) or multicharacter monograms (PKG123) but I generally like T5378 first, at least.

(We only have ~30 reasonable monograms, most of which are used, and it's rare to need to refer to a package.)

Yes.

https://secure.phabricator.com/book/phabcontrib/article/adding_new_classes/

It's true. It's fair to say I was born for it.

We have one, Phrequent. This is a prototype and very far down the list of development priorities.

It looks like the culprit is likely in first-party code:

That bump for the INSERT is expected when you enable the profiler -- it's just saving the profile itself (the page as a whole will run a bit slower, too, which is normal/expected).

I expect that kind of stuff to be a good fit, yeah.

Sorry, we don't offer support with third-party custom development. See "Supported Issues" here:

Ah, it sounds like you really want something like "Create Supertask" -- the opposite of "Create Subtask" -- rather than something more like "Create Sibling Task", which is where related/followup were previously headed.