If you believe you've found a bug in Phabricator, please report it by creating a new thread on Discourse.

Last follow-up -- no, it was not a custom policy. The log of changes to the Project configuration show that the original setting for the edit policy was indeed "Project Members", which seems to indicate that Phabricator was incorrectly preventing new members from editing the Project.

I was unable to reproduce this with a new Project, which makes me suspect the problem isn't a bug in Phabricator. I suspect the Project that was not editable *actually* had a Custom policy with specific users added to it, rather than a "Project Members" policy.

I ran into this issue today as well. The context was a Project created by a regular user a few months back. He added himself and one other user to the Project. He also set the edit policy for the Project to be "Project Members." A few months later, a couple of other users were added to the Project, but neither of them could edit the Project (all links in the "Manage" UI were disabled, can't create milestones, etc.). The users who were in the group when the edit policy was set were still able to manage the group. One of them had to change the edit policy because the newer members of the group could not.

Just ran into this issue on a freshly installed Ubuntu 16.04 docker container.
Actually it's just the package phpX.Y-xml what is missing.
In my case it was php7.2 so all I needed to do was:

sudo apt install php7.2-xml

(No extra repositories needed...)

We no longer offer support for this kind of problem (that technically has reproduction steps, but is sufficiently involved to reproduce that no one has time to follow them, e.g. build a new server from scratch with assorted specific software versions).

This report is generally unclear / hard to reproduce / unusual so I'm not sure how to move forward. It's likely mooted by D20181.

If you want me to look at something, file a report on Discourse with reproduction steps that I can follow to reproduce the issue. I don't need any other discussion or context. I do need working reproduction steps.

No.

@epriestley I have seen you working on Mercurial stuff. Can you take a look at my findings above?

Ok, I think the problem is here: https://github.com/phacility/phabricator/blob/master/src/applications/diffusion/controller/DiffusionServeController.php#L816

I've managed to find the root of the problem, I think. Here is the actual error message that arises somwhere deep in Phabricator and then gets cut turning into non-informative ** unknown exception encountered, please report by visiting:

I still having this problem. @rafaelrabeloit, had you chance to fix or work-around this?

No clue how to reproduce this.

This doesn't seem actionable and is likely mooted by T13098.

I believe this was fixed by D17558 and discussed in T11050.

i met the same issue, and i found the root cause was the OpenSSH upstream issue.

The company I work for doesn't use Phabricator anymore. If I recall correctly the issue happens when an error occurs when creating the working copy. So DryDock create a copy 'copy-123' for example and then if an error occur (during the creation of the working copy for example can't fetch the repository), the build is stopped and the folder 'copy-123' is not deleted. DryDock will retry after 15s and create another copy 'copy-124'. So you can end up with millions of folders after a couple of hours.

I'm unable to reproduce this by following the instructions provided, at least after changes in T13073. Here's what I did:

This is possibly connected to T9548 but we don't know how to reproduce this and can't fix issues we can't reproduce.

We don't have reproduction steps for this and thus can't move forward.

We haven't received the information we need to move forward, so I'm going to close this. Feel free to follow up here or open a new task if you're able to provide detailed reproduction instructions we can use to reproduce the issue locally.

I can't reproduce this. Here's what I tried:

Thanks for updating your report with reproduction instructions, they were very helpful in reproducing and fixing the bug.

I have added some more details. Let me know if you need any more.

Ok sorry, I will improve the report.

We haven't received more information on this, so we don't know how to reproduce it and can't move forward. Feel free to file a new issue in the future with complete reproduction steps, per above.

We don't know how to reproduce this, so we can't move forward, and haven't received more information in several days.

We don't know how to reproduce this, and haven't received more information in several days.

Next steps:

This doesn't appear to describe a bug in Phabricator.

I'm just going to nuke this since there's no repro. This workflow has also been rewritten on the experimental branch and the specific error encountered here should now be impossible.

@exp10r3r you still need to provide reproduction steps. Based on the ones provided, I cannot reproduce any issue using a new/clean install on Phacility or locally. That doesn't mean there isn't a bug to fix, but without the specifics needed to observe and troubleshoot the issue, we have no idea where to start or what to look for. Because we provide support for free, it's on report submitters to fill in all the details needed here. We can't assist with that. No other install is reporting this issue, so it's unlikely due to any change from the upstream.

Specifically, reproduction steps are a set of complete, detailed steps we can follow and see the same issue you are seeing locally. Bonus if you've taken a new, clean image and reproduced the issue.

Currently, Fixes T123 in a commit message means this:

Basically, you're choosing to use a singular task status to track the various lifetime stages of a bug through multiple branches, which isn't what we intended that field for. It's just as easy to expect QA to want to re-confirm the bug is fixed in master as it is your workflow. I think you should track QA in a custom field.

It still doesn't sound like a bug to me, or maybe more specifically, understand what you expect the upstream to fix.

@avivey If you follow the steps in my description, you should be able to reproduce the problem. I'm also attaching a screenshot which indicates that a maniphest was reopened from "Accepted" to "Resolved" twice because the merge commit msg also contains the original commit msg "... fix T...."

We need to have enough information to actually see the problem happening, so we can figure out what's wrong, and maybe even test a fix.

@avivey I updated description to include version info, repeatable and steps to reproduce, is there anything else you guys need?

I'll just ship up the "unbreak" diff, and you can either counter-diff me or figure out something else.

I think more narrow reproduction instructions are:

Yes on the Almanac project profile.

Thanks, let me check that task and I tell you.

This might be a variant of T2465. There's some workaround described there that might help.

• Windows version is Windows 7 with latest updates,
• PHP version 5.6.13,
• svn, version 1.9.4 (r1740329), compiled Apr 24 2016, 15:40:35 on x86-microsoft-windows
• arcanist version mentioned above

This is a little light on reproduction steps. Can you give us more information such as the version information on Windows, SVN, local arcanist, if you attempted reproduction against a clean Phacility instance or against SVNTest here?

After fiddling with some more upgrades, I started to get

Just faced that problem on my micro hosting. I've updated some software and then started to get the same error as OP when cloning/pulling/pushing mercurial repos. Here is the list of software, that got updated back then: https://paste.kde.org/pqelvuhjf

This is currently expected, although we could consider changing it.

When I turn on bucketing, I can't see it actually. Although I do have a lot of diffs, so it could have overheated.

Where does it go when you turn on bucketing?

👍🏻 😄

This still needs complete reproduction steps to be accepted into the upstream. My suggestion is find another VM and load out what you expect the issue is with, and give us those details. Right now it sounds like you're just guessing and that's outside of what we expect when following Contributing Bug Reports. See https://secure.phabricator.com/book/phabcontrib/article/reproduction_steps/ if you need more guidance on providing these steps.

We don't know how to reproduce this and can't move forward.

We don't know how to reproduce this.

That's expected, and not a bug. "Blocking" is currently a top-level status. When a reviewer becomes "Rejecting", they are no longer "Blocking". This doesn't matter in terms of the workflow, because both "Rejecting" and "Blocking" prevent a revision from transitioning to "Accepted".

I've repeated this again, taking some screen dumps. This time I did it on a Phacility hosted instance, instead of on our self-hosted instance.

@dainysunil you need to provide full instructions to reproduce this issue in an untainted environment.

@chad -we tried the upgrade once again .. but the issue is still there

My only guess here is something is corrupt, incomplete, or not upgraded properly. I don't see anything on our side that would lead to this state.

If you believe those are the full, complete steps to reproduce the issue then please take the time and launch a clean test environment and follow the steps and let us know if they are complete.

@chad you need to try upgrade phabricator from branch abff6dc8a9b4e081d74beaf8f062223cb5308ec3 to reproduce the issue. Can you consider this as step to reproduce the error.

We don't accept bug reports without reproduction steps.

Please find the image with upgrade branch. While upgrading the phabricator from this branch we found this error. Please check this upgrade to reproduce the error.

If you believe you've found a bug in Phabricator, we need all the information discussed in Contributing Bug Reports to move forward. Specifically:

We need reproduction steps to move forward. See Providing Reproduction Steps.

Thanks @chad for the help and motivation~