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:

I'm going to merge this into T11036, which specifically describes subproject columns.

One concern I have with this is that the largest sequential milestone may not be the "current" milestone. If you're currently in Sprint 4, someone may reasonably create Sprint 5 before Sprint 4 concludes.

Per above, this is working as intended. I'm open to implementing "Copy Columns from <Previous Milestone>" if anyone actually wants that, but it seems like I may have just made it up. Feel free to file a new task if you'd like to see it.

Yep, that looks good to me.

For (2), the specific problem is that there's no way to look up the milestone PHID, right? If you have the PHID I believe maniphest.search lets you find tasks tagged with a particular milestone:

I think this should be fixed by D17146, which landed a few hours ago. Presumably you're running some ancient stone-age version of Phabricator that's 6 or more hours old?

I think I got all of these, but yell if you catch any more.

This should do it:

(After T12071 we will almost certainly require "E", so you could get ahead of that now.)

Actually, it looks like PHP defaults to "EGPCS" but ships with config files that use "GPCS" (??? why would you do this ???), so this is probably not something that got changed or configured intentionally or accidentally.

Perfect, thanks! That's what I expected, so D17148 should resolve this. Alternatively, setting that value to "EGPCS" (without upgrading, just restarting the daemons) should also resolve this.

I believe this is now fixed at HEAD of master. You should be able to pick up the change with arc upgrade now (if you run master) or in about 36 hours (if you run stable).

While I'm chasing this down, can you show me the output of this command?

This is an unintended side effect of D17100 but resolution isn't straightforward.

This is D17122 interacting with some extremely high-quality code in arc.

This is far afield from an actionable bug report.

Using postfix instead of sendmail

We could possibly remove it entirely since I think it isn't useful for 99% of users, but D17144 just fixes the command.

That one is somewhat interesting because the user created a safe-looking object, then edited the objectionable content into it. I had hoped we might see a few years of uneasy peace before things escalated so far.

I think this really is the same as T10687, but the jittery bad degenerate behavior is only when a scrollbar gets added, so probably laptop + mouse works to repro but not laptop + touchpad?

Thanks for the excellent bug report with high-quality reproduction steps. Your clear, thorough reproduction steps made fixing this issue extremely easy!