T12635 had another similar report, and I believe I tracked down and fixed the root cause there.

And thanks for the report! Let us know if you run into anything else..

This should now be resolved at HEAD:

Actually I think there's a real path to this which remains available:

Here's a script which will identify affected users. Output is:

I think some very old users got into a bugged state where their primary email is verified but the "is verified" flag was never set on their account. We saw one of these users on admin.phacility.com earlier, but I wasn't able to identify a way that a modern account could get into this state.

Problems do not reproduce when downgrading svn client:

We run into this as well, mainly when uploading photos of flipover sheets and whiteboards (to Maniphest or Phriction). Our workaround for now is to ⌘ + click, so the image will render directly into the browser instead of using the lightbox.

This reproduces for me at HEAD:

The keyboard reticle probably has the same issue but we can figure that out later.

Oh, this actually is the inline reticle, not the keyboard reticle.

Oh, the highlight itself actually is a little off if the reply is threaded. We move the comment up a little bit to make it visually thread a little more cleanly, but the highlight doesn't get a corresponding offset.

I'm going to try putting this on top of everything and using pointer-events: none to fix all the attendant click/hover/select issues.

There are three different highlights at play here, visible in this screenshot:

In T12617#221287, @ftdysa wrote:

@nervus70, I use satis to do this and it works fine with phabricator. You should easy be able to use https://secure.phabricator.com/api/diffusion.repository.search to generate the satis config if you have a ton of repos.

Easy changing of a subtype of an existing task would be on my wishlist too. In our worklow it happens fast, that a bug report or a task is tranformed to a story in the next sprint. To edit the subtype in some simple way would greatly help.

Evan, rP52c4715bbcfb solvedthe issue. Losing low-resolution profile images is no problem.
Thanks for the quick solution!

One thing I noticed. All three daemons (Taskmaster, Trigger, PullLocal) are listed as "Waiting" on my install currently, and also show up in the output of phd status. When this problem occurred, I didn't look at the Daemons app in the web UI, but I did notice that Taskmaster was not listed in the phd status output. I'm guessing that behaviour is not normal and perhaps provides a little insight into what's going on here.

I've adjusted my monitoring to just alert me instead of restart the daemons when there's an issue so if/when this happens again I can investigate more fully/provide more information. The code from D17397 had definitely landed when I experienced this, as I saw it in the source code when I investigated. I've upgraded to current stable now.

The Aphlict logs should probably get consolidated here too, they're set up a little weird and don't currently rotate during normal deployments.

After fiddling with some more upgrades, I started to get

It is intentional that daemons shutdown when they aren't doing anything. See T12298. They will be restarted automatically when work becomes ready.

Just faced that problem on my micro hosting. I've updated some software and then started to get the same error as OP when cloning/pulling/pushing mercurial repos. Here is the list of software, that got updated back then: https://paste.kde.org/pqelvuhjf

I made a diff (D17780) that adds bin/phd check which runs the setup check that the web UI runs, writing the result to the console, and exiting with an indicative status. This at least allows the circumstance to be detected and I can fix up the problem with bin/phd restart. This might be good enough. Even though using bin/phd start or having Phabricator self-repair through the Overseer would be better, it's likely too rare to warrant work on more complex options.

This is a bug in the upstream. D17770 (or some similar patch) should be available later today.

I have a rough cut of this one.

https://secure.phabricator.com/rSVNTEST10

Doorkeeper is the correct upstream project to follow for two-way integration in the long run, it's just not on any roadmap currently. You can extend Phabricator yourself today for these things if needed.