This is effectively fixed by T13098, which modularizes test output.

This doesn't have a repro and will probably be fixed via rewrite / modernization in T13077 anyway.

See PHI801. This is a similar case to the one above, but I think the underlying use case was a bit more compelling: the install was transitioning from a set of older web nodes to newer web nodes as a part of a general infrastructure upgrade, and making various fixes to the deployment and support software as part of that process. One aspect of these adjacent fixes was changing the path from /something/something/phabricator to /something-else/something-else/phabricator (I think as a consequence of adjusting deploy strategy), so newer nodes would have a different absolute path than older nodes. Both sets of nodes were in production simultaneously.

The workaround does not work for me on Debian 9.5 with OpenSSH 7.4p1. Actually I am surprised this worked for anyone, since the issue appears to be that the buffer of the pipe between ssh-auth's stdout and the parent's stdin is being filled, hence ssh-auth blocking at some point. It should not matter how fast these buffers are being filled...

We have a more reliable break for this now, in the form:

I can't get anything to break at all now. 💁

I made a change like this to split responses into small blocks and give each a random chance of failing (I tried 4096 and 4027, a prime near 4KB, as miniblock sizes):

A recent, probably more concrete issue that I've seen is that wget of a large file can succeed (wget automatically resumes) but we can end up with a file that has different content than the original, which is disastrously bad.

Confirmed on PHPUnit 7.2.2 👍

This problem fixed by T13140. Thank you.

Since there's no known actual problem with this today, I don't plan to fix it.

I don't currently plan to change the remaining edge case behaviors since I'm not sure they ever occur in the wild.

Duplicate of T8936?

I confirm the Maxime Corteel patch to be working with PHPUnit 7.0.1 too.

I think this is sort of less bad/weird now, at least. You get a tokenizer instead, which is still empty, but you're prompted to "Type a repository name..." and the UI isn't this odd empty select thing anymore.

is there a chance that this problem will get fixed?
The change D17989 is already from May 2017 without any reviewer...

I believe the behavior of this UI should generally align well with what reasonable users might expect, now. In particular, /src/backend and /src/backend/ are now exactly the same in terms of actually resolving ownership, although the UI will continue to show you the value you entered (to avoid confusion where someone types /docs/README.md and the UI echoes back /docs/README.md/ and they have a reasonable concern that the path wasn't understood).

Probably better is to add pathIndex

See T13092; tangentially, it might be nice to render these stories more explicitly as "X added Y, removed Z (because Z is a subproject of Y, and objects may not be tagged with multiple mutual ancestors/descendant projects)", if some sufficiently terse phrasing can be found.

D19111 doesn't fix this in the general case, but should produce the desired behavior for most inputs such that the input is in the form [x](y) and y is the URI of a Wikipedia article.

The intent isn't unambiguous in the general case, consider: Blah blah (see also [x](y)).

Ah thanks!

The non-bold ones also open in a new tab.

Oh! Yes. Sort of.

Just curious, but is the bold effect intentional in the "No Encoding Relative" scenario?

After changes T13073, I am no longer able to reproduce this. That task has made some improvements and may have fixed whatever happened here.

It isn't currently retroactive: the fix is in transition logic and the transition just didn't trigger before.

Is this retroactive to builds in this half state prior to this commit and
deploy?

D19032 now renders D123 in text contexts (plaintext email) as D123 <https://dev.tyrellcorp.com/D123> instead of https://dev.tyrellcorp.com/D123.

D19030 marks this as fixed: it removes this documentation.

I've been running into the same issue for a while now. Using the Default Policy set to Subscribers for Files works well when adding files to Phriction pages and Maniphest tickets. However, when adding binary files as part of a Diff the creator of that Diff needs to change each files permissions by hand before a reviewer can download the Diff. Moreover, this needs to be repeated for every new version of that Diff.

See T13060 and T7339 for followups and additional discussion.

We have also found legitimate users who have valid email addresses (Irish users) that are not accepted.

For those visiting from the future via search, I have decided to publish an unofficial bug patch in a github repo, as it breaks once in awhile due to upstream changes.

Thanks @mcorteel, I'll take a look.

This report doesn't include working reproduction instructions so we can't move forward.

I can't reproduce this; it may have been fixed by D18776 + D18778.

@cmmata here is my diff. It can probably be improved, but it works for me:

@mcorteel I have the same problem, arc unit only works with phpunit 5.7. If I use 6.5, it fails. Do you have that patch anywhere with public access so we can use it while it's not published?

This is resolved as far as I'm aware. See also T11767 (improvements to these limits), PHI125 (similar issue with non-UTF8 attachments failing to insert) and T13053 (planning).

This is quite old and I have no idea how to reproduce it and thus no idea how to fix it. Locally, I tried a few things and wasn't able to identify a case where the Herald field value differed from my actual project list.

From https://bugzilla.mindrot.org/show_bug.cgi?id=2496, this is apparently fixed in the OpenSSH upstream (https://github.com/openssh/openssh-portable/commit/ddd3d34e5c7979ca6f4a3a98a7d219a4ed3d98c2). Since this is a bug in OpenSSH, an upstream fix is available, and the impact is fairly narrow, I don't plan to work around it in Phabricator.