T6996 is adjacent.

This report does not appear to describe a bug in Phabricator, and does not include version information or reproduction steps.

I'm probably done for the night, here's a quick update:

We need this for T4571 for the cluster status console so it doesn't take 10000 years if replicas are down.

Yeah, that should work fine. To promote, you'd update the VIP stuff and Phabricator could remain in the dark.

I think the answer is yes:

I think this is fine to close for now -- the discussion probably remains relevant going forward, but I can point back here the next time a driving use case arises. I think we're unlikely to pursue any of this "suggest a patch" vein of changes on our natural roadmap for a long time.

This is now deployed and appears to be working.

✂✂✂✂✂
✄✄✄✄✄

Sounds good -- yell at us (or maybe CircleCI?) if you change your mind.

This "shouldn't" be possible: the overseer should restart them if they fail. And if the overseer dies, all the other daemons should die.

See also earlier on the page:

Why do you believe the documentation is inaccurate?

You can now start daemons at a low level by piping JSON into scripts/daemon/phd-daemon:

This is almost a year old and we have no idea how to reproduce it. If anyone hits this, feel free to file a new issue with reproduction steps (see Providing Reproduction Steps).

I fixed the totally unrelated half of this (bad default verbosity of phd debug) at some point in the recent-ish few months.

We got rid of this warning in favor of automatically reloading after config changes, which should survive HA setups without additional work.

I don't think this made it to 100% of callsites but we have reasonable saturation now, are populating it on newer tasks, and haven't hit any issues where this information would be useful in a long time. I'm just going to call this resolved-enough, we can add more of them if we're still missing some as needs arise.

This was a very long time ago, but I think the root cause of whatever was happening was really conflated with some other issue.

I believe D11874 covers the last of this for Git.

We don't currently tell CircleCI which user to run as explicitly -- I'd guess the user the build runs as is determined by the token we use.

I'm merging this into T10751, which is a cleaner followup without two years of outdated history. The goals remain the same.

That's my expectation too -- the user cycles their "2012 Hackathon Winner" badge out for "2013 Easter Egg Finder" once they get bored of it, so badges are always fresh and lookin' fly.