At this point, I don't anticipate this ever coming upstream. This is probably a good candidate for third-party maintenance after T5055.

This doesn't seem to be cropping up terribly often and I think this use case is fairly weak.

Presuming something fixed this.

This might happen eventually, or as a side effect of T7303, but the use case here is pretty narrow and there's currently no customer interest so I don't currently anticipate building it.

There are two flavors of this:

Password management is in good shape after T13043 , and this would now be fairly easy to implement in a general way by adding a check in PhabricatorAuthPasswordEngine->isUniquePassword().

There are probably some stragglers that have yet to turn up, but we appear to have survived this largely unscathed.

In T12145#242682, @joshuaspence wrote:

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

In T12588#242719, @epriestley wrote:

If any of these lists only have one form (or the user can only see one form), we'll take the user directly to the specified form.

When users click "Create Subtask", we now look for a list of possible subtask forms.

This is a great badge!

See D19829 for a followup change: getDetail()/setDetail() should be more-private APIs than they are today, and callers elsewhere (like transaction logic) should use methods like getEncoding(), not getDetail('encoding').

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

Ah, thanks! Yeah, that looks like the same thing. I think the bug title isn't quite correct (runtime is dramatically worse than O(input), but not infinite) and the analysis is slightly misleading (escaping the $ doesn't matter, I think) but the patch looks like it will get the job done (although, offhand, I'm unsure about the ($|(?=")|(?=\$) groups).

FYI, I think this upstream issue with pygments addresses this issue (was open since 2016, but only recently had a commit made to fix it): https://bitbucket.org/birkenfeld/pygments-main/issues/1257/infinite-loops-in-specific-files

Mostly, there's just relatively little interest from paying customers right now. PHI64, PHI675, PHI723 and PHI985 are all somewhat interested, but they're generally low-priority / "nice-to-have" sorts of requests, or this is a tangential or supplemental approach that might help with some other problem the request focuses on. Since there's limited customer interest, this isn't a very high priority right now.

Is this functionality blocked on something else?

Ok, I think the problem is here: https://github.com/phacility/phabricator/blob/master/src/applications/diffusion/controller/DiffusionServeController.php#L816

I've managed to find the root of the problem, I think. Here is the actual error message that arises somwhere deep in Phabricator and then gets cut turning into non-informative ** unknown exception encountered, please report by visiting:

I still having this problem. @rafaelrabeloit, had you chance to fix or work-around this?

This isn't an actionable task. It covers too much ground, describes too many features, and most of it lacks compelling use cases.

No plan to continue on this?

I don't expect we'll need to do anything here, mostly just wanted to be able to dig up a list of these if something does come up.

Are colons (:) supported between the keywords and the objects? E.g. Fixes: adcbdef or Depends On: D123?