I don't plan to support this because it makes improvements to milestones which depend on them being ordered ("move to next milestone", automatic date ranges, etc., per above) more complex to implement or use. All use cases here seem to be addressed by "use subprojects instead of milestones", especially after T11036. I'll make the ordering adjustment described above.

I don't currently plan to implement this. I think T5474, T10333, T11036, and using the Maniphest list view with "Group By" address this use case to varying degrees (if you "Group By: Task Status" and then turn your monitor sideways, you pretty much get the desired result). It's possible we'll end up back here in the future, but since I'm not planning to scope this into T13074 I'm going to close it until those changes land and further use cases arise.

Workboards have offered access to multiple task creation forms for some time.

I think D18665 seems to generally have been satisfactory here, so I'm going to call this resolved until additional use cases arise.

This task is a giant mess with pretty much no remaining actionable use cases. See T13074 for plans. If you want some use case here included in that, file a description of your problem via support pact.

I don't currently plan to do this. At a bare minimum, T5474 may moot it.

Some of this is fixed; the rest of it doesn't have outstanding customer requests.

When a blueprint uses concurrency-limiting slot locks, it currently just returns a random lock if it can't find a slot it suspects is free. This makes "all slots look fill, waiting for something to free up" ambiguous with actual collisions. It would probably be better to distinguish between these cases and make it more clear which one we're in.

After the patches above, I can't reproduce any bad behavior for T11495 or T10559.

I'm unable to reproduce this by following the instructions provided, at least after changes in T13073. Here's what I did:

After changes T13073, I am no longer able to reproduce this. That task has made some improvements and may have fixed whatever happened here.

My HoaxBlueprint does not implement activateLease(). This causes leases to be broken and destroyed.

Slightly more broadly: if the lease starts actually activating, we can't be sure that we can undo its state in the general case so we need to throw it away. But this failure (where the resource it has acquired doesn't activate) carries no such risk, and we can safely just throw it back in the pool. I think the only state we need to wipe out its its slot locks, which are easy to clean up.

Note that there's another similar scenario:

I just removed the setActivateWhenAcquired(true) for now without changing behavior. Next issue:

Alright, next issue:

Leases and resources don't use standard header UI tags to indicate status:

When logs span multiple lines, they are rendered as unreadable garbage messes:

When blueprints claim to be able to allocate resources but fail during allocation, we currently destroy the lease. I think this is likely too severe: consider an EC2 blueprint where the allocation call fails for some temporary reason (EC2 just fails, or we hit the account limit for instances, or whatever else).

In trying to plot a course through this, I'd like to try to sequence this so that existing issues get fixed first, then breaking changes happen afterward (maybe in the next release). Some of these changes (particularly, the CustomField-to-EditField change) will be significantly disruptive to existing custom code. (That change is also pretty straightforward and new stuff depends on it, so I'd probably start there if there was no compatibility concern.)

See T13072 for Harbormaster followups.

This doesn't really describe anything actionable.

This is something we could reasonably build now, but I think we're unlikely to build it without a customer request and an actual use case. Closing until those materialize.

See Planning.

When the dust settles, I expect

In any case, I think we're left with two issues:

This deadlocks: the first connection has the revision row locked FOR UPDATE and the second connection is waiting on that lock to clear before its update fires. This is an application-side deadlock and MySQL will not be able to detect it, so the request will appear to hang until the query timeout (or execution timeout) is reached.

Sorry, the only way to influence feature development is through a support pact. See also Planning.

The NULL is explicable if we can somehow queue a HarbormasterBuildWorker between the time it is created by harbormaster.queryautotargets and the time the TYPE_UPDATE applies.

Here are the irregularities that jump out to me for the PHI268 data:

For PHI268, here are the actual diffs for the affected revision:

All normal buildables should be created with containerPHID set properly already in the modern code.

For the Harbormaster races, I'm looking at the containerPHID case first since this is a relatively concrete clue (PHI268).

Unit tests caught one issue with D19059 in the password upgrade engine. The code looked like this:

Please use the Discourse community forum or your organization's Support Pact to get help with support questions.

For PHI332, my test case was:

It isn't currently retroactive: the fix is in transition logic and the transition just didn't trigger before.

On the races: