This is now up, and rCORE knows how to deploy instances in this tier.

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).

One issue that we constantly face is as follows...

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.

To be honest, the paste I was archiving was a fork of another paste which I generated when I wanted to find out how forking a paste works.

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.

Ah yeah, it seems that is the case.

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

Does user_b watch #project_one or #project_two?

No, both rules are a custom action which notifies a HipChat room.

Do Herald rules 26 or 29 send them mail?

Owners and Badges also have this inconsistent archiving flow.

For reference, the mail ID for @chad closed this question as resolved is 69826.

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.