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.

In Chrome (Version 64.0.3282.140 (Official Build) (64-bit)) the inline comment buttons have a hot-spot for tooltips to party

See Planning.

Is there someone working on this feature?

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.

@epriestley Would you guys be open for a patch for this? How would you like to see this implemented in order to be acceptable for you guys?

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:

@epriestley Ah okay sorry, I'll do that! But I think the first part is a bug.

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

My use case for a Webhook: Trigger a stage build when a commit is pushed to an untracked topic branch.

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.

Is this retroactive to builds in this half state prior to this commit and
deploy?

On the races:

lol, 2 years old report is closed with we-don't-know-how-to-reproduce-it :D

See also PHI356.

This report doesn't meet the reproduction instruction requirement for modern bug reports.

See also PHI356.

This hasn't blown up in 24 hours and is about to promote, so anything else can be handled in followups.

(Testing "secure" flag in webhooks. 🐑)

See PHI357.

I'm not entirely sure this resolves the original request, but we have webhooks now. See also PHI348 and PHI349. There's some documentation that should publish shortly and the changelog should have more details in the next couple hours.

I'm planning to build T11330 ("policy-blind" webhooks) instead, and deprecate feed.http-hooks. See that task for details.

Will this be promoted to stable release of Phabricator?

Seems OK:

(I've muted this task so I shouldn't get mail about it.)