This happened again today, presumably because I added a new differential revision to PHID-TASK-bclylvkmj6c5kdn74s26.

Yeah that works but I feel like making the file view a bit more responsive would help as well.

Walking through some use cases, roughly in increasing order of complexity, and general behaviors -- this is all me just imagining things, not necessarily the best way forward:

Does this fix it?

If you type this:

This is the task for it.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

Okay, can you file a separate issue for that and I'll try to reproduce it? That's bad and not the expected queue behavior.

Would roles be able to have a list of default Projects (or Space?) which members of the role are added to? Or should we expect to migrate to role-based permissions?

commits without UTF8 data in them effectively block the queue.

there could be info in saved searches

Is this really a case of information being useful to an attacker?

To address two things immediately:

This one is a bit magical and needs some adjustments after changes from T8726.

(I did so.)

That change doesn't fix things retroactively. I can delete draft 315073 if you really don't like that specific bubble.

Can you construct a plausible scenario where this information is substantially useful to an attacker?

I would argue that showing stuff to users that cannot be used is a UX bug.

(I haven't tried to reproduce this.)

There is no way to do this right now. T4103 will provide a way.

Repro instructions are:

For my own reference:

(or posting, I tried just submitting and it wouldn't let me)

Specifically, I would expect the comment to appear in the preview at the bottom of the page, but not be visible inline in the diff itself.

It looks like you have an unsubmitted inline on line 70 of PhabricatorBadgesRemoveRecipientsController.php with this text:

If you scroll to the bottom of the screen, is there a saved value for "Action"?

This reproduces locally for me.

I didn't get as far as implementing this, but my intention was to make clicking the token eventually take you to the object's page (for example, the project's detail page or the user's profile page), not select the token.

Based on context (in T8906) and previous discussion, my guess is that you're trying to make the "Projects" field required. I'm going to merge this into T6030, which discusses solving that root issue (among other related issues).

We'd prefer to solve this by letting you make the "Projects" field required, since that's the actual root issue. I'm going to merge this into T6030, which is the general blocker for that.

I haven't seen any reports of actual users experiencing real confusion. If and when we do, I'd prefer to tailor any solution here to their actual confusion (e.g., what were they expecting to see, what were they trying to do, why did they find this confusing), and imagine that hiding these applications is probably not the best solution (offhand, another solution might be marking these applications as admin-only instead). In legal jargon, this issue isn't "ripe".

This isn't quite the same as T7804, see T7804#127310 for discussion.

These aren't quite the same. One is a new condition/field, which would let you write rules like this ("mail me about all zebra stuff, except if I took the action"):

Don't you mean Differential?

In any case, is it expected that line numbers are being copied in the unified diff case?

Do you have an example where copying the right side of a diff currently does not work like you expect/want it to?

When copying from Phriction and transaction diffs (for example, the diff shown in "Show Details" on a transaction like "alincoln edited the description for this task."), you're also copying out of a diff which we've inserted artificial linebreaks into. These linebreaks are inserted prior to diffing, and these diffs are generally of very low quality. There's some discussion in T3353 of improving these diffs to be word-based instead of character-based, which is likely to substantially mitigate issues around linebreaks and the generally low quality of these diffs.

In 1-up, there's no ambiguity and we can improve this behavior.

No, it's enabled for your accounts only.

Ah, I think this is relevant...

I destroyed F641702 and F641705.

We aren't going to ship with the Phriction content.

OK. If I get rid of the explicit phd.taskmasters setting then it seems to work. With phd.taskmasters set to 8 it seems to lock up at 100% CPU usage after a few minutes.

This has happened three time today :(

Reasonable defaults are set by default.

Hmm. It has happened again, even with --autoscale-reserve 0.25.

That change adds a "safe mode" for specific accounts, which prevents them from using the console to disable instances and instructs them to contact support instead:

However, here's another suggestion: don't allow people to disable instance outside of Phacility conservative work hours. This way it's guaranteed that in case of a mistake, one can reach support immediately.

I don't know what the reasoning is to prevent people from doing this, but

In T8878#126901, @chad wrote:

I'd rather over-engineer a more generalized "new in phabricator" type feature, so people understand what new functionality was added since their last update.