I think we'd likely want to pursue T8646 first and see if that resolves this on its own.

Some day you'll be able to spin up a container or host per build and tear it down afterward, but doing so creates a performance/efficiency tradeoff because you have to build and tear down more state per build. I suspect this tradeoff is undesirable for this project even if the code existed to make it (because host startup / teardown would likely overwhelm build cost).

D14117 discusses a vaguely related case where a blueprint might intentionally deny lease acquisition on a resource that it needs to process further. This pattern seems fine conceptually if/when we find real resources in the wild which fit into it.

This block has been removed in D14114 and we no longer distinguish between "lost an allocation race" and "all resources are currently full". The logic goes:

This is likely something we can improve, but I think it probably just follows T6139/T9123. I'm just going to close this until those get built and we can re-examine it if it's still problematic.

I think there are two components to this:

See T9427 for the C... issue.

Countdown and Audit both use the C prefix after D13713, so C123 matches both "Countdown 123" and "Commit (with internal ID) 123".

We can and should reduce the amount of memory required here -- I believe it's roughly O(N^2) because we load every user for every user, in order to respect visibility policies. We can reduce it to O(N) by dumping the handles after building the mail.

Here's my best effort to figure out what's happening here:

Do you have D14112?

See also T4136.

If you're running the notification server, the old session should have had a "Page has been updated, click to reload." badge on it. Not sure if you guys have that configured, but that can provide a cue that you're out of date.

Not exactly related, but I also want to:

Cool, sounds good. Definitely no rush on this, I just had the same feeling of things being odd.

I think you can write a Herald rule like this:

This doesn't seem problematic to me. It accurately represents the actions you took (submitting multiple accepts from the web UI and via email) and doesn't create any inconsistencies, problems with revision state, etc. It's a little odd, but the workflow was a little odd.

(No one but me has actually launched a test instance yet, so it's possible that the workflow only works for me and/or is impossible to find.)

We just got an instance like testnumber1 created as a standard instance, so I think this is definitely less clear than it should be. But the new "you can use numbers in your isntance names" stuff works!

Yeah, I'd generally like to make workflows more clear about how they're arriving at results. arc diff is the major culprit here but all of the automatic resolution we do in selecting commit ranges, revisions and repositories can likely be made more clear.

See Planning, Roadmap, Paid Prioritization.

I currently expect to never pursue this.

I can conceivably land that, I think it just never quite felt right to me. Maybe I'll take another look at it in the new design.

One mild concern I have with merging these into "Edit" is that the effects of disabling things aren't always self-explanatory, and this dialog gives us an opportunity to explain effects.

I remember we had this implemented before, but can not find task why it was removed.

Er, execution log, I suppose.

What happens earlier in the stack trace?

I vaguely intend to rewrite all the code which adds recipients to collect the reasons they were added so it says "user_b (watches #project_one, author, added by Herald, subscribed implicitly by comment)" somewhere. But this is a lot of work.

(That should be shown in "Watchers" on the project pages.)

Does user_b watch #project_one or #project_two?

Do Herald rules 26 or 29 send them mail?

Owners and Badges also have this inconsistent archiving flow.

If we refused to arc land in this case it would break this other weird workflow, where you stack multiple changes in a branch with immutable history configured, then amend one of them:

Why is "Commit A" in "Revision B"?

I'm don't see why the number-of-rules is relevant

These aren't linked partially because in the general case, the policy model for Herald rules is a little murky:

Then, I have to do several clicks/typing/copypaste to get to H123 if I want to see why it was added.

See T9408. A security researcher found a low-severity but practical attack against our implementation of dot.

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.

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"?