I suspect this is a "security researcher" manually editing the form to submit bogus values. We've had some activity on HackerOne recently which puts this project in various feeds there, and there are a large number of "security researchers" who do not read the program description at all before attempting to grab some quick cash by finding trivial XSS.

We haven't seen other requests for this and don't plan to let projects be tagged with projects, which is what this amounts to.

Project hashtags are unique, so only one project is ever related to a given hashtag.

I think it would still be reasonable to default wontfix and invalid to an X, but not fussed.

+1 on this from me, but I agree that this is a duplicate of T8345.

Wontfix also has a ticked checkbox.

Specifically, to completely log out of Phacility, you must currently:

This is getting fairly close to working locally but isn't going to make it into this week's release. I want to let the changes in connection with T9307 settle first, and am still unsatisfied with the permission model (currently: anyone who can exit the instance can perform exports) because this capability represents a huge increase in power over any other capability.

Broadly, this behavior is expected.

Is Jenkins restarting the build automatically, or is a human going into Jenkins and clicking "restart"?

The "role" stuff is mostly just practical/technical: we have to do about 95% of the same work whether we end up with multiple configurable sets of defaults or a single set of defaults.

We should probably improve this behavior at some point, but it isn't entirely trivial, I'll likely do concurrently with T9132 anyway, and the current behavior is a little rough but doesn't seem too bad (it's inconsistent and needlessly indirect, but not technically incorrect).

D14097 reverts this because it felt really bad in production, and generally not very promising as a direction we could iterate on and make successful.

For whatever it's worth, here are the comparable (14-day) numbers from this install with the more modern script:

How about we:

D14096 has some screenshots of this and I've pushed it to this server. It may get some design followup but feels relatively reasonable to me in its current form.

T9393 discusses the "Blackbox" extension. To summarize:

Cool, that sounds reasonable. Broadly:

Here's a case where the result feels OK, especially if I'm a new user:

On real data, this feels very bloated to me for tasks, at least:

Can you just disable the extension for Phabricator's copy of the repository?

The erroneous revision is because when hg log is invoked with --debug, it prints arbitrary messages to stdout which we can not distinguish from log output.

Why are you interested in running this extension?

This doesn't feel completely solid to us yet so we're going to try it out for a bit and see if there are further adjustments to make. We're interested in feedback on this version of the feature if anyone has a particularly positive or negative experience with it. I'll push it to this install shortly so it's available to play around with.

See that diff for some details, here's what it looks like currently:

D14095 is a rough pass at this. I'm summarizing (showing the first ~paragraph of content) rather than showing contextual content around body search results. This is easier and maybe-better, given that our search results are more highly structured than webpages? I'm not sure if this holds up in practice.

This should be resolved by D14092. Thanks for the fix!

@berenm suggests what is likely a simpler fix here:

See also T7004, although I'm generally not hopeful about being able to build a version of that which feels like it works well.

What if we do this?

I get some odd results locally, in MySQL too, although I have a very small table on my laptop (~1100 rows):

No.

The fact that it's not using the key at all explains why the GC was slow for you and why removing the ORDER BY improved performance, at least, but it seems like it should be able to use the key to execute this query efficiently, and appears to do so in MySQL (we don't have as much data as you do, but I don't recall the GC having any issues when we pushed this change here, and other large installs haven't reported issues but I'd expect them to if the GC was not able to use the key).

I'm tentatively inclined to think that this is a bug in Percona, since:

Yuck. Can you come up with any query where it uses the key? What if we do something really dumb like this to try to trick it?

Out of curiosity, what's the query plan for this (DESC instead of ASC)?

Hmm, that's surprising. At least on our dataset, I get a worse-looking query plan without the ORDER BY:

We do not currently support git notes, and I had never heard of it before this task.

Yes, this looks consistent with the GC and publisher deadlocking.

That just looks like a bug that's only tangentially related, I think Audit and Countdown are both trying to receive mail at C... addresses.

Create a dashboard panel with the query, then embed it with {W...}.

I don't plan to pursue this. We'll offer JS access to the OAuth API instead (see T7303).

Maybe renaming "Arcanist Client Results to "arc lint + arc unit" would be clear enough? It sounds like this workflow is generally fine, users are just not making the connection between "Arcanist Client Results" and the "arc" client?

I don't see an especially clear way forward here:

This is not blocked, although it's a moderate amount of work (4-6 hours?) and not adjacent to other work.

This is 1-2 hours of work and can be slipped in somewhere if approved.

We can look at this as part of the next Phriction iteration, although other changes likely impact the eventual design here.