✂✂✂✂✂
✄✄✄✄✄

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.

There was some unrelated discussion, but I think the original idea was to have a dashboard panel which is only this (panel on its own):

Dashboards need too much work to make this straightforward.

A treatment that might be nice is to add an "Events" sidebar panel, similar to the existing "Badges" panel. It could have a link to view their full (public) calendar (in the Calendar app), and show a quick view of current/upcoming events.

I think there may be a different/better fix to D13354, or maybe I'm not remembering why we made some decisions.

Hmm, odd. That definitely isn't the POST issue (although I suspect that may be an issue in some cases). The behavior will hopefully be more clear once master promotes, and definitely easier to debug. I'll dig into it a bit on my side in the meantime, I have a few ideas of things to try now. Thanks for your help!

Oh, I think I might know what's wrong. If you repeat the same process with a viewable file (like a JPEG or PNG) does that work?

Hmm, I'm not immediately sure -- that all looks correct on your side to me. Let me add some kind of basic LFS administration page that shows Phabricator's view of LFS objects in the repository -- hopefully that will shed some light on where things are breaking down.

That's probably (?) the repro.

Oh, I think I see.