Intentional; see T12026 and T12027.

Thanks a lot for the quick fix here. Works great now. Was the change to get rid of potential arc commands in the Diffusion review intentional or is that also a bug?

Thanks for the report. This should be resolved at HEAD of master. Let us know if you run into anything else.

This was collateral damage from D17164.

Hurray, thank you!

Please include reproduction steps. This is always required on every bug report.

After D17169, the clusterize command, the error message, and the documentation should be more helpful in anticipating and resolving this situation. (The documentation may take ~24 hours to actually regenerate.)

I marked D17168 as fixing this -- it just makes the replacement migration more robust, but I think that's the best we can do from the upstream. No idea how null ended up there in the first place, but I'd guess we have no way to figure it out and our lives would be no richer for knowing.

Aha, of course. Thank you!!

You should be able to safely update these rows to have '' instead of NULL, then continue:

I'd be happy just to have a good workaround, since I don't think we're particularly attached to these mostly-contentless rows. My ideas for possibilities so far are:

• Delete the offending differential_hunks rows manually. I worry that this might cause some inconsistency.
• bin/destroy the revisions containing the offending hunks. This seems a bit heavy-handed though.

Ah, sorry, I overlooked that you're using edges.

Doing that without defining getFieldTransactions() in my class yields this exception:

Transaction with key "1" has invalid type "devTestPHIDs". This type is not recognized. Valid types are: update, comment, title, summary, testPlan, reviewers.add, reviewers.remove, reviewers.set, repositoryPHID, tasks.add, tasks.remove, tasks.set, view, edit, projects.add, projects.remove, projects.set, subscribers.add, subscribers.remove, subscribers.set, phabricator:auditors.

Oh -- try subclassing DifferentialCommitMessageCustomField instead of DifferentialCommitMessageField directly?

Thanks for the help Evan. I've gone through and converted everything as you suggested. The conduit method then started telling me

I can't reproduce this; we can't move forward without reproduction steps.

We're going to need complete reproduction steps. Preferably against a Phacility test instance so we can rule out environmental causes.

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, and I suspect it was fixed some time ago during changes related to T6027.

I've collected some guidance more formally in T12085.

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

Thanks! D17162 should clean this up.

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

I believe there's more to it than just the bundle2 setting that causes it to not work. It still breaks for me even with devel.legacy.exchange=bundle1:

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.

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.

Voila.

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?

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.

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

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.