I can't reproduce the issue you describe following your steps on this server. Do you have any suggestions on what I could do differently to reproduce the bug?

official website click related "Close As Duplicate", browser send two request.

Started building and insanely easier as an application. "Favorites" unless you have a better suggestion. Seems more flexible.

In T10382#191728, @durin42 wrote:

For now, I'd suggest that if phabricator breaks bundle2, filter the response to the capabilities command and omit bundle2=.* from the response.

To be clear my suggestion was only for using 3.4 from client machines. Server machines can still be kept up to date.

Note that my suggestion in https://secure.phabricator.com/T10382#191728 is still what I think /should/ happen: if Phabricator insists on trying to parse the Mercurial protocol, it should absolutely not include capabilities it doesn't understand when queried by the client.

Running vanilla Mercurial 3.4 should not be recommended as all vanilla versions older than 3.7.3 are vulnerable to a trio of CVEs, the most likely exploitable being CVE-2016-3630. Instead, Mercurial <4.0 can be configured to disable bundle2 via the experimental.bundle2-exp=false config option and Mercurial >=4.0 can do the same via devel.legacy.exchange=bundle1. Both of these options are undocumented. I discourage their use. But as a workaround for Phabricator, they are preferred to exposing clients to known security bugs.

After reviewing the state of the world in related tasks:

Voila.

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?

(And again, to emphasize, I'm happy to drop this if y'all aren't interested. I have my solution and am happy ignoring this, but just thought it might be something you guys would want to check out.)

Head as of my Dec. 17 post in this thread. Can roll forward, but was hoping to wait till the edit engine migration settled a bit.

What version of Phabricator are you currently running?

@epriestley any suggestions?

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?

Thanks for the warm welcome to the community

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

Sorry for wasting your time. For the record:

.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.

ok forget it. works fine in other browser.

Chad's House ?

How do I reproduce that?

@epriestley maybe also related? Some files are just missing in Conpherence now.

I am currently using project.query rather than project.search. I presume the change you suggest for .search would work for query too since my recollection is that project.query also doesn't return milestones. I tried to use .search originally, but noticed that the attachments available were limited and didn't correspond to the documentation (examples mentions projects, subscribers, but then later on only watchers and members are supported) so I was scared off by the 'may change' warning:-) I can switch to using .search if that's the better thing to do - I presume you'd add attachments for the new types of information to be returned?

My misunderstanding on this btw, I assumed mov was an option, not a default.

Anywho, I can't reproduce this in a local sandbox or on Phacility, so assume something is hokey with how files are served maybe in secure.

My expectation per Contributing Bug Reports is people submit bug reports they see on their real install. Otherwise we have no idea now to prioritize if something happened here testing vs. something people really hit in day to day use. Filing it here also means an upstream developer must respond to it.

I expect it to work, because it looks like it is supposed to:

And I think most people can't play them.

Why do you expect mov's to work? To my knowledge, this server isn't configured to support them.

I did some further digging and made a little progress

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".

Sorry! Will do.

Please use your own install or a Phacility instance to test Phabricator. I appreciate that you're finding bugs, but this is our real install, not a demo.

Ah ok

I don't think we mention every commit in the changelog?

I may have missed it but it doesn't look like this was mentioned in any changelog in December/January - or is this not yet in stable?

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.