Yeah, this is a little obscure since I was trying not to build more than we needed. The URI comes from DiffusionRepositoryManagementPanel->newEditEnginePage(), which does this:

I dinked around on this but for the life of me, can't find where it's getting the URI from. I did learn how paging works in EditEngine though.

Thanks!

Follow the instructions in Restarting Phabricator.

There's no pathway forward here without reproduction steps.

I think we'll manage. (:

Yep, sry, I didn't know that that was your test account, but @epriestley told me at IRC.

I added those for a reason.

Presuming this is resolved, but let me know if I'm missing anything.

also affected by this, same report/errormessage.

well now

So these are all unreachable commits that have now been imported?

In T11188#181667, @epriestley wrote:

Are all of these events commits?

I've never heard of anyone running into an issue like this, and there are no tools to clean it up.

Are all of these events commits?

I explained this above, in T11187#181641.

Why the customfields are not displayed in the history in the maniphest view, but only once in details?

See T3179.

I dont want to impersonate. I want to preserve a history from a redmine stack using a customfield like edited-by. Unfortunately this field wont be displayed in tasks/all. What should I do?

No. Phabricator is explicitly designed to make it impossible to impersonate other users.

May is it possible using a maniphest.customfield like 'edited-by'?

By design, it is not possible to impersonate other users over Conduit. There is no transaction you can construct which will list any user other than the authenticated user as the author.

Thx, could you give me please an example transaction, where another author than 'user' will be listed in history as editor?

When you apply a group of changes with a *.edit endpoint, they are all applied at once, as though you had submitted an "Edit" form or a comment with actions. In particular, this means:

We haven't seen any other users run into difficulty with this, but we'll keep an eye on it and consider updating the documentation if we see further confusion.

OK, I understand now what is the point

OK, I think I get it

That also doesn't look like a working copy.

I should have checked if there exists a verbose output first :-D
Anyway, here is the output :

14:21 grooveek@anlin ~/Projects/test-phabricator%  arc install-certificate --trace                                                           
 ARGV  '/home/grooveek/Projects/arcanist/bin/../scripts/arcanist.php' 'install-certificate' '--trace'
 LOAD  Loaded "phutil" from "/home/grooveek/Projects/libphutil/src".
 LOAD  Loaded "arcanist" from "/home/grooveek/Projects/arcanist/src".
Config: Did not find user configuration at "/home/grooveek/.arcrc".
Config: Did not find system configuration at "/etc/arcconfig".
Working Copy: No candidate locations for .arcconfig from this working directory.
Working Copy: Path "/home/grooveek/Projects/test-phabricator" is not in any working copy.
Usage Exception: Specify an explicit URI or run this command from within a project which is configured with a .arcconfig.

Working Copy: Path "/home/fl.blondeau/NetBeansProjects/namescan-phabricator" is not in any working copy.

Can you try arc install-certificate --trace, and show me the output?

As it says clearly on the home page, this is not a test install - if you want to try something launch a free Phacility test instance.

If there have something to know.

Sorry this isn't a place to test, I quote:

I tried to reproduce your steps :

name

Cool. The expectation is that this won't happen again going forward (we should automatically compute reachability from here on out). Let us know if you see it again in the same repository. If we get a few more reports maybe I'll make the error message mention this command.

That did it, thanks!

Try bin/repository mark-reachable rXYZ (and show me the output, maybe)?

Thanks, this is working now.

Let me know if that doesn't fix things. Expected behavior is:

Thanks for all the help digging into this, there is pretty much zero chance I would have guessed that on my own. I think D16149 should fix this properly, I was able to reproduce a similar error once I knew what I was after.

This is in all likelihood a mistake made forever ago but I'll wait for a potential patch.

O.o

Okay, I figured this out:

Thanks! Looks like we have things flipped for some reason. Let me see if if I can track that down. I think I should have a patch in an hour or so, or I'll let you know if I need anything else.

object 78daf8de9fe15dce0b4d0e1945a57c778e0536d7
type tag
tag v2.11.1
tagger Test User <test@test.com> 1413916998 -0400

tagging v2.11.1

We should be able to parse any repository in any state, so don't delete the tag!

If it requires us to delete the v2.11.1 tag then so be it, we understand that maybe we did something wild with history in the past but that tag doesn't really give us anything anymore so it can go.

Had to redact a bit:

(I suspect v2.11.1 is a tag-object and the tag-hash and object-hash are getting mixed up somehow, but hopefully the full command will shed some light on things.)

Hrrm, I'm very confused by that behavior.

The repo uses callsign P and refers to Platform.

Can you show me the output of these commands?

In T11085#181202, @scode wrote:

@eadler Did you have enough insight/recollection as to whether all our reported cases were due to users editing in the web UI?

If I have to write code and drop it into my local install to reproduce the issue, it's custom development and it's not supported. The documentation may be incorrect, but like a prototype, it's not intended to be ready for end-user use (only internal developers).

I did not ask for support in third party development.

See T5447 for more details on the state of app development,

Damn man you're good.

We don't support third party app development.

Run your-package-manager install php-xml or php5-xml or php7-xml or whatever it's called on your system.

I saw the issues about windows being generally broken. I sympathize with the team's plight having been there too many times with cygwin and git bash over the years. FWIW I think the best approach is to normalize the path references back to unix format as fast as possible. The approach of mapping driver letters C:\ D:\ to /c and /d etc is reasonable. Beyond that there is the usual handling of spaces and () {} etc to consider where php/bash might get confused.

So I managed to resolve this eventually. It looks like the underlying cause of all the problems was that the SSH daemon on the build server itself had got into a weird state where it would accept connections, but not initiate an actual SSH session.

So I manually set the resource to a destroyed status, cleared out drydock_command and saw Drydock attempt to start allocating a new resource. However, now I'm getting:

I just encountered the same problem and this solution worked for me as well. Thanks @DheerendraRathor !

Ah sorry for the confusion. I was trying to keep up to date on the weekly updates and didn't realize this flow had changed. I'll look at upgrading in the following week or two.