@wakes, Yes I'm reproducing the issue on a local install.
Here is the configuration:
Distrib:

Centos7-64

This report does not include reproduction steps. We can't move forward on bugs we can't reproduce. See Contributing Bug Reports.

Our current thinking still is that it's environmental, that is something between Phabricator and the browser is munging the JS (or the webserver itself). Generally anything this catastrophic would be (JS failure) we'd have multiple easy to reproduce reports, and we haven't seen that. It is concerning though that three people ran into this in short notice. It'd be good to know if there is any common infrastructure (web, php, server, etc).

Ah, OK, I thought that message from clemvangelis about 6 up is a confirmation of local install issue? I'll see if I can do a local install and replicate...

We have not been able to reproduce any issue. If someone can come up with a set of steps or environment that reproduces the issue, then we can look into it.

Hi guys, I'm a bit confused re the commit hash message above, does this mean it's an issue which will be looked into as is happening on a local install also?

Yes..
nz_cor:_nz_fm_integrationnz_cor_nz_fm_integrationnz_cor_nz_fm_integrationnz_cor_-_nz_fm_integrationnz_cor_nz_fm_integrationnz_cor_nz_fm_integration
Is in there now.
I'll remove those.

I'm not really sure what's going on. The limit on the slug column is 128 characters, and that project name is nowhere near that (we should raise a better error message than we do, but I'm not sure how you're hitting the issue in the first place).

/var/www/phabricator# bin/storage adjust
Verifying database schemata...
Found no adjustments for schemata.

Can you show me the output of bin/storage adjust? (For now, decline to apply any changes it suggests.)

Actually changing it back is failing with

Prior to T9551 (circa October 12), projects could generate with invalid hashtags, but I don't think these ever worked (at least, many of them definitely did not work).

I wish I could reproduce it.
But all new projects I create work perfectly fine.

The original report in Q272 is almost certainly unrelated.

Initially reported in Q272 by @linan

Resolved by D15019.

Added a proposed patch. See additional comments in the diff.

It is intentional that anyone who can configure the application (in this case, Maniphest) can edit all the forms for it (and can see them in order to edit them), so it's expected that you can manage and reconfigure the form in configuration UI.

*nod* I found that task and used it to clean my arcpatch branches. If I may make a suggestion, could arc patch try to be clever about it and overwrite arcpatch-D69 only if there are no local modifications, and/or after confirming with the user?

My bad, the phabricator commit is the following one: f59ebf4c09598e5f02657a4037c822b64a306646.

f4d47d93fd8a56f918e4cfa72bf96d6997955a8d is not in the upstream. We do not support forked versions of Phabricator.

On a local install, we are also getting this error.
phab : f4d47d93fd8a56f918e4cfa72bf96d6997955a8d
libphutil: 0fa7efbf09d75b7803ef54bd6c72ee3c69a964e4

Yeah, I agree your suggestions are more clear (and "Entire Diff" would be a little murkier).

We do not support the Bitnami image.

There is no such option.

If you already have a branch named arcpatch-D69, it is intentional that we do not overwrite it. You may have made local changes there, and it would be very bad for us to destroy your work.

Hi, I am also getting this issue on a relatively clean build of Phabiricator via bitnami image on Google Cloud VM, using Firefox and Safari. It happens whenever I choose any existing task and click on 'Edit Blocking Tasks'. There's only a few tasks in the system and I can replicate by creating a new task in the backlog and then clicking the 'Edit Blocking Task' button. What comes up is a dialog as per screenshot image:

That shouldn't be a problem. I'll take a look at doing something later in the week, time permitting.

@epriestley Yeah, I understand. If you cannot reproduce it you can't fix it. ;)

I was able to reproduce the error message with the obvious, invalid input:

Very strange. I solved it temporarily by removing the group from the list of reviewers. That way I could at least update the diff. We've had similar issues in the past. The issue appears to mostly happen when you try to update a diff that was created before the upgrade (and not necessarily new update).

I'm going to close this out since I think there's no way for the upstream to move it forward for now, but file another issue if you hit a second wave of stuff or reopen this later if, e.g. all the fixes were terrible no-good garbage.

I'll upstream regex changes if they include unit tests.

After the above, I ran arc diff origin/master --trace to update the revision. Got approximately the same screen (with "Differential Revision" now populated), saved and exited, got a clean update (see D15002).

Oh, you're reporting that updating causes the error, sorry. Let me try that.

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

Different (albeit related) bugs:

D15000 will make capturing no text mean "the whole file", and documents the behavior. You can either change your regexp to not capture "0":

Well, maybe that's overkill.

I believe D14307 changed the behavior from "fatal horribly" to "work". It's possible that capturing 0 meant "whole file" at some point (although I'm confused by T6303 if it did) but I think that was accidental and don't believe we suggested/recommended/documented that anywhere.

Hmm. I thought I had seen that somewhere. Oh I see what I did. I followed the filename linter code and noticed that it called:

Instead of the line being 0 (meaning whole file)

This is very similar to T6303.

Looks like you are already aware of T8404, and this is a dup; Why did you submit another ticket?

Thanks so much.

Also for posterity, I discovered that I was able to take a task in which this link works as expected and break it simply by assigning it to myself. Removing the assignment to myself and forcing uncached page refresh did not unbreak the task (so now I seem to have another one in permanent workaround state). This is still not a very detailed reproduction scenario, but maybe if someone hits this, it will help hone in on the problem.

Alright, I think you should get different behavior at HEAD for both of those issues. No promises it will be correct, but let me know if those changes just uncover a second series of errors.

I also don't think it's wholly unreasonable to change the prefix rule to be stricter, but I think getting rid of the username@ stuff will moot it in all realistic cases. We could look at the rules after the next Conpherence update if we want to reintroduce the username@ rule.

Ah, that makes perfect sense. Thanks!

The mail looks like this:

How is it even getting mail addressed to, say, jonah@company.com if the system's mail is handled by Postfix and the aliases file only pipes phabricator@ to the Phabricator script?

Phabricator strips the prefix if it is present, but does not require it to be present, and attempts to route all mail for the domain it is given.