T12089 has a narrower description with some screenshots, I think the behavior got flipped by accident.

The "Ambiguous Leaders" section in the docs should more or less cover this, and using bin/repository thaw to promote your favorite node to leadership is probably the easiest way to resolve it. This pathway to ambiguity is fairly mundane compared to what the documentation imagines, though, and both clusterize and that UI warning could point toward bin/repository thaw --promote. I'll make these more clear.

Thanks, not intentional.

I can't reproduce this either. Here's:

Alright. If we don't hear back from you in a few days we'll close this since we can't move forward on it, but you're free to file a new task when you're ready to move forward.

I can't reproduce this, and I suspect it was fixed some time ago during changes related to T6027.

Oh, one final note:

I've collected some guidance more formally in T12085.

I've also made these additional changes, not directly related to the original request:

I think this is mostly guidance I neglected to issue, sorry about that.

Thanks! D17162 should clean this up.

These changes are now available in HEAD of master, and should be available on stable after Jan 13. master is also safe to upgrade into right now, although some T11114 stuff may churn later this week.

All evidence points to this and T9548 being the same task, right? I'm just going to merge them.

After reviewing the state of the world in related tasks:

I'm going to merge this into T12074. Summarizing things so far and my short-term plans:

For T5214 / T12074, I am moving forward with an API query model where columns are associated with another, different object as a boardPHID (currently, always a project), and boards do not have their own objects or PHIDs.

You can also safely cherry-pick that to test if it resolves things, it doesn't interact with anything else.

That is: rP65c1c758ed261f65c8164d200ce01373ae5b822c

If you upgrade past 65c1c758ed261f65c8164d200ce01373ae5b822c (both stable and master have this change), does it reproduce?

What version of Phabricator are you currently running?

The *.search endpoints are preferred now, but the guidance we provide on the Conduit page could use some updating. I'll rework this a little alongside other changes here.

I'm sorry you found this interaction frustrating. How would you prefer we have handled it?

The Phacility cluster is on 2017 Week 1 now and I can't reproduce this there, either:

Thanks for the report! We were just missing a "/" (Quicksand does not follow redirects, which I think is desirable, although maybe we'll change that eventually) but D17151 should fix this up a little more robustly.

Specifically, here's what I believe the bug is, in rough terms that probably get some specifics wrong:

This can either move forward as a bug report or a consulting request.

It was installed from a FreeBSD package

.mov thing is likely an interaction between range requests and encryption. It works for me in Firefox. It only affects media files for installs which have configured file encryption and there's no data corruption/loss so I don't plan to get to it for a while unless a real install hits it.

How do I reproduce that?

Yeah, this is in stable, just didn't make the cut for individual mention in the changelog. I think it promoted in Week 52 and I just lumped it into "Differential got infrastructure changes".

I think we're back in action and I have learned a series of valuable life lessons.

(This host is the replica database for the "Files" application partition, so even if I had to completely burn it to the ground nothing would be lost.)

I foolishly ran apt-get dist-upgrade because I am bad at computer and the motd said I should.

I wasn't able to reproduce this earlier so I'm not sure how to move forward, but feel free to follow up if you have more information.

One thought here is that updating variables_order is fine on the server, but I really don't want to force arc users to muck with php.ini. Some possible "solutions":

I'm going to merge this into T11580 because I think that describes what remains here.

I briefly dug these up: