Slightly easier is:

I was able to reproduce this, possibly, by following these steps:

No disruption is expected and there was no maintenance or known disruption at those times. Nothing jumps out at me immediately in monitoring, either, and I can't reproduce this by casually cloning stuff.

D16396 should make us raise a narrow error for "ids": [], "phids": [], "whateverPHIDs": [], etc., instructing you to pass a nonempty list.

I think fixing "ids":[] is trivial; it just works like that because we use the same Conduit type ("PHIDList") both for constraints and other things which can accept an empty array (like setting subscribers to [] to remove all the subscribers on an object).

(@yelirekim, just a heads up since whatever comes of this might impact you somehow.)

Great! It looks like we're down from about 18K to 3K on repo001 too, so it appears that this pretty much works as expected.

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

This has promoted to stable and doesn't seem like a contentious change so I don't currently anticipate any need to keep this open or revisit it.

Personal Herald rules do not run for disabled users, so disabling a user will disable all of their personal rules.

I also don't necessarily consider this a bug (I think a human explicitly @mention-ing a user definitely should add them again, and that quoting someone is pretty close to mentioning them, and that reasonable users could probably expect either behavior, and perhaps that the "add them again" behavior is more obvious or more expected) but T11035 discusses this and some other behaviors which have varying amounts of grey area.

The use case in that linked task is "using Remarkup to demonstrate the behavior of a different markup language", which isn't something we expect Remarkup to support.

Why do you want to link part of a word?

What specific steps can I follow to reproduce this issue? See Providing Reproduction Steps for help.

See additional discussion in D9343.

I added you to Community, granting you sweeping janitorial powers on this install.

It's not 100% reliable but we can use that to make a pretty good guess.

I deployed this stuff, and I'm actually seeing more used ports now on secure001 than I did in D16389. However, I think most of these are coming from web requests and the larger count is because we have more traffic during US daytime than we did earlier in the morning. It didn't occur to me earlier that I'd be accidentally counting connections from both sources.

No problem, thanks for the report!

I think this was resolved by D16381, I just didn't deploy it until a moment ago.

How did the author/reviewer know it was ready to go upstream in this situation?

Check this out if you haven't seen it yet?

We don't currently plan to bring any more third-party linters upstream. Instead, we're going to make it easier for users to write and distribute linter bindings themselves.

You could also do this with no custom code by using Herald to trigger a Harbormaster build and having that make an HTTP request to something which runs the logic, or theoretically by using feed.http-hooks or Doorkeeper (although these are probably better after T10363).

This reproduces for me as described.

Presuming this is resolved since we haven't received any more information in about a week.

• We'll provide a third generation differential.diff.search endpoint eventually which will be able to do this lookup in a modern, consistent way, but have no particular timeline on this.
• I'm open to accepting a patch to add 'phid' to differential.querydiffs in the meantime.
• I don't want to bring "Diff X" upstream as an object name. This (English word + space) is inconsistent with other object names, ambiguous in some contexts like CLI revision messages, surprising in other contexts like fulltext search from the global menu, and faces more internationalization issues than existing monograms.
• You can create repositories via third-generation API methods, see Diffusion User Guide: Repositories API for guidance.
• See T9766 for Herald control via API, although neither that use case nor this use case are very strong from my perspective.
• Harbormaster will get more API support eventually, but see below.

In the general (Phabricator, rather than Phacility) case we could also suppress that warning while "NUX Mode" is active, for whatever "NUX Mode" means. Presumably, it's not important to fix until you get through whatever NUX flow we end up with. This would indirectly reduce the annoyance for Phacility instances, although sync is still better.

@jmeador, this error should no longer be misleading in HEAD of master. Let us know if you run into more stuff, and thanks for the report!

We definitely should sync it, and probably at least some other stuff, like language and pronoun, which may not be relevant now but is likely to be relevant in the future.

I'd be more comfortable just saving the description if we didn't have CustomFields. I think we do something similar in Phriction today.

See also T7216, which I plan to solve primarily via T5307. This isn't too closely related, but is a somewhat-similar Dashboard configuration usability issue.

Yeah, I think we're definitely going to build T8250 before anything here or on T11451.

This discussion also doesn't really seem to define an upper bound on this feature, at least to me. If some explicit classification ("issue" vs "non-issue") is good, why isn't more better? Almost all of the arguments for this classification seem to support adding many different options ("compliment", "suggestion", "fyi", "issue", "really important issue"), perhaps multiple dimensions of classification ("serious comment", "joke intended for humans"), etc.

wow sorry :(

My expectation is that intent is conveyed with the plain text of the comment without requiring any real effort on the part of the reviewer, and that the use of human language allows reviewers to express a very wide range of types of feedback.

D16385 increases the storage length of the underlying column. Summaries will now be cut to 255 bytes or 80 display glyphs, whichever is shorter.

See D16384.

I think this is resolved as best it can be today, let me know if you still have questions.

Put another way, we're routinely asked to work around bugs in other software by applying patches to Phabricator, mostly because we're usually pretty responsive and have a short release cycle. For example, T11362 asks us to work around an unusual behavior in some GUI VCS tool, rather than asking that tool to adjust the behavior. Sometimes putting a workaround in Phabricator is reasonable, but I think that in most cases the onus should be on that other software to work correctly. If we took this to an extreme, we'd end up shouldering a huge complexity burden for bugs in other software.

(For now, I'm inclined to let this and T11450 run their courses and then talk about how we can improve meta-issues afterward. I think both of these tasks will serve as good examples of our concerns.)

Primarily, global rules bypass access control policies. They can also apply different actions.

See also T9367, perhaps, where users apparently accepted changes with serious bugs because of timezone differences between remote teams, although the exact use case behind that task remains murky to me.

I will say that even if it is the same rate of honest carelessness, reducing it even by 0.5% would be very helpful in preventing massive bugs/incidents.

I don't currently have any plans to change the behavior described in T10109. At least there, I think the behavior was just confusing when testing rules, and not actually bad. My inclination is to try to find a way to make the behavior more obvious instead of changing it to resolve that confusion.

(I have no idea on this either, the related object task search is definitely fulltext.)

We truncate these summaries at 80 bytes because the underlying storage column is text80, which is only 80 bytes long when represented using binary collation in older MySQL without utf8mb4 support. We can not store more text in the general case without changing this column size.

Not in the Phacility cluster today.

There's no real way to do this today, since this isn't a workflow that I think we've seen in professional environments.

In T11450#189540, @chad wrote:

Personally my only anecdote is additional controls actually slow me down.

For example, I can describe several different levels of "careless mistakes", after the author lands a revision without addressing the feedback:

I could imagine a possible future like:

Try editing it from the central administration console:

As a reviewer, I cannot distinguish between a comment I expect the author to take action on and a comment I do not expect the author to take any action on.